[SDL] No unicode information in key releases

Koshmaar koshmaar at poczta.onet.pl
Tue Jan 25 05:11:46 PST 2005


 
> In a GUI context, whenever a key is pressed, you react to that event. If left is
> pressed, you move cursor one char to the left. That's it. You don't need to
> store anything or even handle SDL_KEYUP events. Of course, you need to use
> SDL_EnableUNICODE() to get usuable infos. You will also use
> SDL_EnableKeyRepeat(SDL_DEFAULT_REPEAT_DELAY, SDL_DEFAULT_REPEAT_INTERVAL), to
> properly handle key repeat.

In my code, reaction to keypress resulting in sending event is *completely* up to application/subsystems/tasks; GUI code shouldn't care about handling all the gory details, because it's what input system is for. GUI just needs to call one function which loops through array of keys and returns the first which is non zero (that is - pressed) and if anything was actually pressed, "event" is fired; it's very simple system but it works ;-)
So, input system is responsible for storing all keys in one, centralized place; application (and other systems) then can do with it what they want, but with many tasks that do input reading using different methods that can be pretty awkward since constant re-changing of mode would be needed (theoretically, in practice it won't be the case, BUT etc....), and that's why I wandered if there's better way then changing states.

 
> So, you need to switch from one mode to the other depending on the context. For
> example when you see in your main game loop that user pressed, say, F12, then
> you clear all key pressed, set a flag saying you're in GUI mode, and draw your
> dialog box. Depending on the type of game (realtime or not), you will go to
> another loop (in which case the games is paused) or continue in the main one,
> but handling keyboard differently since you're in GUI mode.

Ok, thanks! "there's no other way, you have to change states" - maybe that's not what I wanted to hear, but it looks like there's really no ther way.


Koshmaar




More information about the SDL mailing list