blackberry/GamePlay — pull request #20 by bslack (2012-01-17 14:19:42+00:00)
Title: Next

- Added Keyboard support to iOS
-- Feel free to re-arrange the source code, just note, that by default the compiler gives warnings if the c functions don't have prototypes, so I recommend keeping them in, other then that, I just put my c functions near the bottom of my source files out of course of habit, if you move them back to the top I will leave them there going forward

- Corrected issues that prevented things from working on a 64 bit platform. I don't know if my fix is the one you will want to go with or not (nor is it necessarily the one I would recommend). What I would recommend is the following:
Some where in base.h or some other common include you define your own types, e.g. typdef int gint32 or something like that (perhaps using stdint) and do it per-platform. The size's of ints, longs, etc can change depending on architecture, and this abstraction would make life much easier. I typically do this for my cross-platform libraries (usually I stick with stdint). It helps makes things explicit and would avoid the issue that I encountered. e.g vector with unsigned long which is 4 bytes, and functions that take pointers to unsigned longs (also 4 bytes), work fine on 32 bit systems, but on 64 bit unsigned long is 8 bytes, therefore reads at sizeof(unsigned long) read more data when in reality you want 4 bytes. On 32 bit intel systems unsigned long == unsigned int in terms of bytes, therefore either would work.

Anyways thats my two cents. You guys might be okay with just changing the AnimationController to accepting unsigned int's instead, I was uncertain if you wanted it a long for another reason, so I avoided changing it and instead added the new function to package to explicitly declare the read size and not rely on sizeof(T) where T is an unsigned long.