In porting my engine to SDL2 from 1.2, I ran into an interesting issue now that the SDLK_ enum values are not (mostly) tightly packed. The highest enum value went from 322 to a really big number.
In my engine, I store the state of all keys as follows:
keystate_t keycodes[SDLK_LAST];
This is handy for a number of reasons, including tracking whether a key is rising or falling in a given frame and for passing around the structure to various GUI objects which can “eat” various keycode events as they trickle down an event queue.
I’m sure I can work around this, but before I do, is there an expected course for someone who intends to store keycodes outside of the SDL_PollEvent loop?
Use SDL_SCANCODE_ for tracking keyboard state.On Wed, Aug 21, 2013 at 11:09 AM, Michael Labb? wrote:
In porting my engine to SDL2 from 1.2, I ran into an interesting issue now
that the SDLK_ enum values are not (mostly) tightly packed. The highest
enum value went from 322 to a really big number.
In my engine, I store the state of all keys as follows:
keystate_t keycodes[SDLK_LAST];
This is handy for a number of reasons, including tracking whether a key is
rising or falling in a given frame and for passing around the structure to
various GUI objects which can “eat” various keycode events as they trickle
down an event queue.
I’m sure I can work around this, but before I do, is there an expected
course for someone who intends to store keycodes outside of the
SDL_PollEvent loop?
On Wed, Aug 21, 2013 at 11:09 AM, Michael Labb? wrote:
In porting my engine to SDL2 from 1.2, I ran into an interesting issue now
that the SDLK_ enum values are not (mostly) tightly packed. The highest
enum value went from 322 to a really big number.
In my engine, I store the state of all keys as follows:
keystate_t keycodes[SDLK_LAST];
This is handy for a number of reasons, including tracking whether a key is
rising or falling in a given frame and for passing around the structure to
various GUI objects which can “eat” various keycode events as they trickle
down an event queue.
I’m sure I can work around this, but before I do, is there an expected
course for someone who intends to store keycodes outside of the
SDL_PollEvent loop?
Thanks for the pointer to the new scancode stuff. Unfortunately, I need mapped inputs for my purposes. A GUI that does not use the native mapping feels wrong.
Michael Labb?On 2013-08-21, at 11:14 AM, Andre D wrote:
On Wed, Aug 21, 2013 at 11:09 AM, Michael Labb? <@Michael_Labbe> wrote:
In porting my engine to SDL2 from 1.2, I ran into an interesting issue now
that the SDLK_ enum values are not (mostly) tightly packed. The highest
enum value went from 322 to a really big number.
In my engine, I store the state of all keys as follows:
keystate_t keycodes[SDLK_LAST];
This is handy for a number of reasons, including tracking whether a key is
rising or falling in a given frame and for passing around the structure to
various GUI objects which can “eat” various keycode events as they trickle
down an event queue.
I’m sure I can work around this, but before I do, is there an expected
course for someone who intends to store keycodes outside of the
SDL_PollEvent loop?
I believe you can use something like SDL_GetScancodeFromKey and you
should be able to track the key state mapped to a particular keycode.On Wed, Aug 21, 2013 at 2:20 PM, Michael Labb? wrote:
Thanks for the pointer to the new scancode stuff. Unfortunately, I need
mapped inputs for my purposes. A GUI that does not use the native mapping
feels wrong.
Michael Labb?
On 2013-08-21, at 11:14 AM, Andre D <@Andre_D> wrote:
On Wed, Aug 21, 2013 at 11:13 AM, Andre D <@Andre_D> wrote:
Use SDL_SCANCODE_ for tracking keyboard state.
On Wed, Aug 21, 2013 at 11:09 AM, Michael Labb? wrote:
In porting my engine to SDL2 from 1.2, I ran into an interesting issue now
that the SDLK_ enum values are not (mostly) tightly packed. The highest
enum value went from 322 to a really big number.
In my engine, I store the state of all keys as follows:
keystate_t keycodes[SDLK_LAST];
This is handy for a number of reasons, including tracking whether a key is
rising or falling in a given frame and for passing around the structure to
various GUI objects which can “eat” various keycode events as they trickle
down an event queue.
I’m sure I can work around this, but before I do, is there an expected
course for someone who intends to store keycodes outside of the
SDL_PollEvent loop?
Don’t know if you want to go this route, but you could make a std::map, then have your keys paired up with the SDL scancodes/keycodes (depending on which you want to use)
so, something like this snippet
std::map<OurKeyCode, SDL_Keycode> OurKeyCode_to_SDLKeycode;
OurKeyCode_to_SDL_Keycode.insert(std::pair<OurKeyCode, SDL_Keycode>(KEY_1, SDLK_1));
then you can do OurKeyCode_to_SDLKeycode.find(keycode) to see if it is there, and if so, set it in your keycodes array.
(If you go the other way, you can do SDL_Keycode_to_OurKeyCode.find(SDL_Keycode) and return your keycode as well, so you could have 2 map tables, it just depends on how you are doing this)
Judy is the ultimate imperative data structure. All operations are O(1),
Comparable to hash tables for random access, insert and delete,
and lists for sequential access (which hash tables cannot do at all).
Judy is a cache tuned digital trie. Its probably overkill for what you want
but once you have them you’ll probably use them for just about everything :)On 22/08/2013, at 5:39 AM, Sparks wrote: