-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
Sam Lantinga wrote:
What I do is use SDL_GetKeyName() and iterate from SDLK_FIRST to
SDLK_LAST (would be 0 to SDL_NUM_SCANCODES in 1.3) and stare all the
names in an array of each key (didn’t have to strdup in 1.2, but it
seems 1.3 implies you should). Then when the user defines keys it just
runs through the table to see what he’s defining (he defines in a Lua
conf using key names). It’s also easy to look up the key name later
when displaying configuration. All this is to avoid defining keys with
their keysym and making life easier for the user (and more compatible
across layouts).
I’m not sure the goal here. When the user presses a key, you can look
up the name of that key and store either the key or the name of the key
in your config. Are you trying to keep the same physical configuration
regardless of keyboard layout?
If you’re trying to keep the same physical configuration, you can store
scancodes and use SDL_GetKeyFromScancode() and SDL_GetKeyFromScancode()
for displaying what’s on the user’s keyboard.
If you’re trying to keep the same logical configuration, you can just
store keysyms and look up their names at runtime for display purposes.
Am I missing something?
Well the idea is to let the player define them easily, by name and not
by keysym. So you can write stuff like “shoot = ‘space’” instead of
"shoot = 32". Of course a more fancy configurator could handle this.
The problem with the keysyms not being consecutive with no SDLK_LAST, is
that you can’t feasible store a table of 2^32-1 names. In 1.2 they’re
consecutive with SDLK_FIRST and SDLK_LAST, so it’s easy to create the
lookup table to translate from keysym name to keysym.
Another possibility would be to create a function like SDL_GetKeyName()
like SDL_GetKeyFromName() and it would return the SDLKey that matches
the char* name.
Overall the idea is to be able to do conversions from name <-> keysym
both ways, while SDL only supports natively one way.
is the best approach because it also seems to break compatibility that
SDLK had with the isalnum type functions since it had pretty nice
mapping to ascii with a few things poking out the edge (function keys,
etc…).
This is still the case, SDLK_* values still map to ascii with a few things
poking out the edge, they just poke out in a way that apparently breaks
isalnum().
Well, I think as much of of the ascii as possible should be mapped to
the ascii positions, and then the rest could be expanded. I wouldn’t
mind doing something like:
int my_isalpha( SDLKey k )
{
return ((k & 0xff) == k) ? isalpha(k) : 0;
}
It’s just soo much uglier if it doesn’t map though. I’m mainly speaking
about stuff like SDLK_BACKSPACE, SDLK_SPACE, etc…
I understand I could just use scancodes, but then when a user (like me)
has mapped Escape to Capslock, it doesn’t read it as Escape as wanted.
This seems like it would be remapping of the keysyms (i.e. a logical
remapping, not a physical one.)
Does it show up that way on your system?
This is my xev output:
KeyPress event, serial 34, synthetic NO, window 0x1800001,
root 0x7b, subw 0x0, time 1868946, (159,-94), root:(1259,712),
state 0x0, keycode 9 (keysym 0xff1b, Escape), same_screen YES,
XLookupString gives 1 bytes: (1b) "ape), same_screen YES,
XLookupString gives 1 bytes: (1b) "es: (61) "a"
XmbLookupString gives 1 bytes: (61) "a"
XFilterEvent returns: False
KeyPress event, serial 34, synthetic NO, window 0x1800001,
root 0x7b, subw 0x0, time 1871690, (159,-94), root:(1259,712),
state 0x0, keycode 66 (keysym 0xff1b, Escape), same_screen YES,
XKeysymToKeycode returns keycode: 9
XLookupString gives 1 bytes: (1b) "cape), same_screen YES,
XKeysymToKeycode returns keycode: 9
XLookupString gives 1 bytes: (1b)
As you can see, the keycode is different, but the keysym is the same.
and after the lookup it’s the same. SDL 1.2 seems to get this fine, but
1.3 doesn’t and must use the first keycode it gets.
To put things into perspective, the SDL keysym corresponds to the X11 keysym,
and the SDL scancode corresponds to the X11 keycodes.
We could fix the few SDLK_* keysyms that actually correspond to ASCII values
(tab, escape, backspace, etc.) to use those values. I think that’s probably
a good idea and I’ll go ahead and do that.
Yes, that would be awesome.
On a side note, you haven’t mentioned keyrepeat. It seems to be on
always. In 1.2 it was off by default and you had the option to enable
it, the function in SDL_Compat to disable keyrepeat seems to be empty.
Is it deprecated?
Other then that it looks pretty fluid and nice, going to try to see how
the rest of the stuff works (haven’t poked SDL_mixer yet), and most
likely see if I can start using fancier stuff (especially like the
haptic subsystem).
Edgar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAklg6wQACgkQolm4VNX3QTy6eACg0yYkrhbj5Fy3YewcUVTJ1Kli
CIEAoIfJIe4+8VXHdIcBOJf84FrjeqBC
=X537
-----END PGP SIGNATURE-----