Why typedef Sint64 SDL_FingerID?

SDL Development
21

Thanks for the correction :POn Mon, Dec 10, 2012 at 10:19 AM, Jonathan Dearborn wrote:

If the ID is a pointer or an incremental index, then it’s not limited to
64 touches. The future is fingerful.

Jonny D

On Mon, Dec 10, 2012 at 9:33 AM, Alex Barry <@Alex_Barry> wrote:

wboe,

You have to remember the cross-platform nature of SDL to understand why
the finger is a Sint64. On some platforms, you literally get a finger
index/id for each touch, so having an integer makes sense, and I don’t see
the technology handling 64 fingers any time soon. For the platforms that
do use internal structures, Sam/Ryan/whomever had to decide if it was
better to use some sort of union with an open pointer available to the dev,
or do some casting with the Sint64. They obviously chose the route of
casting because it can all be done safely internally so the touch api is
the same across all platforms.

For those worried about have 128 bit numbers, that’s ridiculous. 64 bit
technology for everyday use is still fairly young. The processor bits
usually only changes when we reach some sort of limit in RAM, and do you
know the max amount of RAM 64 bit can handle? 128GB - that’s more than any
current computer has enough RAM slots for, and I suspect that’s not going
to change for at least a few years, therefore it will be highly unlikely
that within SDL 2.x’s lifespan we’ll need to support 128 bit computing.
Bringing that back to touch devices, it is extremely unlikely that for
index-based touch events that you will ever have more than 64 fingers at
once - if you think one day there will be some sort of common-use
table/surface for roughly 6 people to use simultaneously with both hands, I
don’t see a reasonable use case for that.

I also don’t see a weighing reason why any dev should go back through the
touch events and change it to a pointer. The Sint64 works quite well for
all supported platforms.

To explain Sam’s response, he is essentially saying there were multiple
ways (“doors”) that are all logically correct to take, and they chose to
use Sint64 rather than pointers or some sort of custom SDL structure.

-Alex

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

22

To explain Sam’s response, he is essentially saying there were multiple
ways (“doors”) that are all logically correct to take, and they chose to
use Sint64 rather than pointers or some sort of custom SDL structure.

Let’s not be so quick to speak for someone else. For all we know, he may
have meant that, of the three explanations listed in the previous message,
he, the figurative “lady in pink”, selected the second (and the prize -
shared knowledge and insight? empty satisfaction in knowing it was an
arbitrary choice?). On the other hand, it could have been an ether-induced
hallucination. Who knows? :)On Mon, Dec 10, 2012 at 10:53 AM, Alex Barry <alex.barry at gmail.com> wrote:

Thanks for the correction :stuck_out_tongue:

On Mon, Dec 10, 2012 at 10:19 AM, Jonathan Dearborn wrote:

If the ID is a pointer or an incremental index, then it’s not limited to
64 touches. The future is fingerful.

Jonny D

On Mon, Dec 10, 2012 at 9:33 AM, Alex Barry <alex.barry at gmail.com> wrote:

wboe,

You have to remember the cross-platform nature of SDL to understand why
the finger is a Sint64. On some platforms, you literally get a finger
index/id for each touch, so having an integer makes sense, and I don’t see
the technology handling 64 fingers any time soon. For the platforms that
do use internal structures, Sam/Ryan/whomever had to decide if it was
better to use some sort of union with an open pointer available to the dev,
or do some casting with the Sint64. They obviously chose the route of
casting because it can all be done safely internally so the touch api is
the same across all platforms.

For those worried about have 128 bit numbers, that’s ridiculous. 64 bit
technology for everyday use is still fairly young. The processor bits
usually only changes when we reach some sort of limit in RAM, and do you
know the max amount of RAM 64 bit can handle? 128GB - that’s more than any
current computer has enough RAM slots for, and I suspect that’s not going
to change for at least a few years, therefore it will be highly unlikely
that within SDL 2.x’s lifespan we’ll need to support 128 bit computing.
Bringing that back to touch devices, it is extremely unlikely that for
index-based touch events that you will ever have more than 64 fingers at
once - if you think one day there will be some sort of common-use
table/surface for roughly 6 people to use simultaneously with both hands, I
don’t see a reasonable use case for that.

I also don’t see a weighing reason why any dev should go back through
the touch events and change it to a pointer. The Sint64 works quite well
for all supported platforms.

To explain Sam’s response, he is essentially saying there were multiple
ways (“doors”) that are all logically correct to take, and they chose to
use Sint64 rather than pointers or some sort of custom SDL structure.

-Alex

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

23

I think you might be slightly off there; the 64-bit address space of
(2^64 - 1) bytes = 1.845e10 GB (or 18.45 exabytes), and indeed you can
buy servers with a lot more than 128GB of RAM. Be careful, someone
might have used this as part of an elaborate cover story to sell you a
37-bit computer.On Mon, Dec 10, 2012 at 10:33 PM, Alex Barry <alex.barry at gmail.com> wrote:

For those worried about have 128 bit numbers, that’s ridiculous. 64 bit
technology for everyday use is still fairly young. The processor bits
usually only changes when we reach some sort of limit in RAM, and do you
know the max amount of RAM 64 bit can handle? 128GB - that’s more than any
current computer has enough RAM slots for, and I suspect that’s not going to
change for at least a few years, therefore it will be highly unlikely that
within SDL 2.x’s lifespan we’ll need to support 128 bit computing.

24

Yeah, I realized my “math” was horridly flawed after stating it :stuck_out_tongue:

I guess there are servers with that much ram, however, how many server
setups with that sort of RAM use SDL and touch screens?On Sun, Dec 16, 2012 at 12:13 AM, Scott Percival <scott at labyrinthdata.net.au wrote:

On Mon, Dec 10, 2012 at 10:33 PM, Alex Barry <@Alex_Barry> wrote:

For those worried about have 128 bit numbers, that’s ridiculous. 64 bit
technology for everyday use is still fairly young. The processor bits
usually only changes when we reach some sort of limit in RAM, and do you
know the max amount of RAM 64 bit can handle? 128GB - that’s more than
any
current computer has enough RAM slots for, and I suspect that’s not
going to
change for at least a few years, therefore it will be highly unlikely
that
within SDL 2.x’s lifespan we’ll need to support 128 bit computing.

I think you might be slightly off there; the 64-bit address space of
(2^64 - 1) bytes = 1.845e10 GB (or 18.45 exabytes), and indeed you can
buy servers with a lot more than 128GB of RAM. Be careful, someone
might have used this as part of an elaborate cover story to sell you a
37-bit computer.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

25

Well, I only have 8 GB in my Linux box, and 16 GB of swap - but you should see
the pointers I’m getting sometimes…! :smiley: Seriously, operating systems do the
weirdest things with pointers - and even more so if they’re 64 bit. Never
assume anything!

As for the original subject, one reason to not use pointers (typecasted or
not) at all for things like this: Fun times debugging if an application is
accidentally holding on to old IDs and tries to talk to SDL about them…

One reason to use 64 bit integers: If you actually get those unique tool IDs
from tablet styluses and the like, that would allow applications to remember
and recognize tools, not just while running, but also across application runs.
Very handy, and expected from programs like PhotoShop, GIMP etc.On Monday 17 December 2012, at 00.42.11, Alex Barry <alex.barry at gmail.com> wrote:

Yeah, I realized my “math” was horridly flawed after stating it :stuck_out_tongue:

I guess there are servers with that much ram, however, how many server
setups with that sort of RAM use SDL and touch screens?

On Sun, Dec 16, 2012 at 12:13 AM, Scott Percival <scott at labyrinthdata.net.au wrote:

On Mon, Dec 10, 2012 at 10:33 PM, Alex Barry <alex.barry at gmail.com> wrote:

For those worried about have 128 bit numbers, that’s ridiculous. 64
bit technology for everyday use is still fairly young. The processor
bits usually only changes when we reach some sort of limit in RAM, and
do you know the max amount of RAM 64 bit can handle? 128GB - that’s
more than

any

current computer has enough RAM slots for, and I suspect that’s not

going to

change for at least a few years, therefore it will be highly unlikely

that

within SDL 2.x’s lifespan we’ll need to support 128 bit computing.

I think you might be slightly off there; the 64-bit address space of
(2^64 - 1) bytes = 1.845e10 GB (or 18.45 exabytes), and indeed you can
buy servers with a lot more than 128GB of RAM. Be careful, someone
might have used this as part of an elaborate cover story to sell you a
37-bit computer.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’