How can I detect keys like SDLK_QUESTION? I think it's behind shift on an american keyboard, but whatever I press, with or without shift, SDL never detects any key as being SDLK_QUESTION, and other similar keys like SDLK_AT, ... (SDLK_PERIOD works for example because that's not a key behind shift). Another question, for some reason KMOD_CAPS, KMOD_RSHIFT and KMOD_LSHIFT don't work, they're always false, wether or not caps lock is down, enabled or disabled, or left or right shift are pressed or not. How to use these KMODs? I'm writing a simple function to input text in SDL, which is why I encountered those questions. Everything works except the things above (currently I detect if shift is pressed with SDLK_LSHIFT etc... instead for capital letters). Thanks.

try testing for two keys being pressed.
the shift key and the '/' key (or whatever is the same as '?')

Does anyone have a picture of the american keyboard layout (because that's what SDL uses), because I can't find one with google and don't know which keys are supposed to be behind other ones. Thanks :)

If you want to know what character the user entered (as opposed to what key), try SDL_EnableUNICODE(1). event.keysym.unicode will now contain the (Uint16) character. You can usually simply cast it to a char and you'll have what you want.
One thing to keep in mind is that the unicode field will only be filled on keydown, not keyup.
You should also disable the unicode translation as soon as you're finished with it because it caused extra overhead.

I'm wondering why you have to turn on unicode to get the ascii of the key? Simple SDL_getch() could have been nice.. I guess they'll write a library for it..
I don't know how symbols are arranged, but I guess you could write a routine to give an ascii equivalent for the key symbol:

return ascii_equivalent[keysym];

The problem with that is that you have to write a different translation table for each keyboard.

The unicode translation uses whatever the operating system tells it, so it's always accurate. I'm guessing the reason that it's using unicode is to make sure all possible characters are possible. There's really no reason not to use it as it works on Win9x too without any special libraries (AFAIK at least).

Quote:

Original post by Gyrbo The problem with that is that you have to write a different translation table for each keyboard.

Does that mean that for example SDLK_z doesn't return z on all keyboards?
Btw, I noticed (by checking out SDL_keysym.h) that SDLK-symbols are mapped to ascii if it's less than SDLK_z.

Feidias: yes, you're right. I'm currently typing on an AZERTY keyboard and I have to use the "w" key if I want to generate an SDLK_z event.

You don't really need the exact letter a key represents most of the type, except for entering your name or something. In those cases, I enable unicode translation to get the key and after the name has been entered, I switch it back off.

I presonally like the way SDL does it, because this way I can still use the WASD keys without doing strange things with my fingers. (Try using Q to strafe left, D to strafe right, Z to move forward and S to move backwards if you have a QWERTY keyboard and you'll get the idea).