Is there a reason that there’s no SDLK_PERCENT constant? ascii 37 is
mysteriously skipped in SDL_keysym.h. If there is a reason, shouldn’t it
be documented in the header?
Could be because no known keyboard (layout) has that as the primary
function of any key… (Does yours?)
The SDLK_* symbols are to be considered portable “scancodes”, and have
nothing much to do with ASCII. Each symbol is supposed to represent a
physical key on the keyboard, pretty much disregarding whatever might
be printed on the keycap. Use these when you want a "mega gamepad"
sort of input device.
Use the UNICODE stuff if you want the ASCII (or rather, UNICODE)
representations of keystrokes when available. (In a normal layout,
only key down events generate UNICODE, and some keys are primarilly
used to alter the keyboard state, affecting other keys; ie “dead
keys”.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Saturday 26 February 2005 22.41, braddabug wrote:
Is there a reason that there’s no SDLK_PERCENT constant? ascii 37 is
mysteriously skipped in SDL_keysym.h. If there is a reason,
shouldn’t it be documented in the header?
David Olofson wrote:
The SDLK_* symbols are to be considered portable “scancodes”, and have
nothing much to do with ASCII. Each symbol is supposed to represent a
physical key on the keyboard, pretty much disregarding whatever might
be printed on the keycap. Use these when you want a "mega gamepad"
sort of input device.
If this is true (and it certainly makes sense, IMHO, as otherwise there
would be no portable way of doing mapping-by-position as opposed to
mapping-by-generated-character - but I haven’t found it stated clearly
anywhere in the documentation), then the current (CVS) implementation on
Mac OS X is wrong.
When I press the middle key in the second row (it’s labeled “Z” on my
Swiss German keyboard), I get either SDLK_z or SDLK_y depending on
whether I use a Swiss German or US keyboard mapping, while I should get
the same code in both cases (I guess it should be SDLK_y, assuming that
the SDLK_* codes are based on a US keyboard).
I could probably look into fixing this when I have time, but that won’t
be in the next few weeks.
-Christian
[…]
When I press the middle key in the second row (it’s labeled “Z” on
my Swiss German keyboard), I get either SDLK_z or SDLK_y depending
on whether I use a Swiss German or US keyboard mapping, while I
should get the same code in both cases (I guess it should be SDLK_y,
assuming that the SDLK_* codes are based on a US keyboard).
Same thing happens on XFree86/Linux. I get SDLK_ symbols according to
my custom swedish Dvorak map.
I think the reason for this is that it’s non-trivial, if at all
possible, to fix on some platforms. I think some fumble the real
scancodes codes away befor applications can get at them.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Sunday 27 February 2005 10.07, Christian Walther wrote:
Christian Walther wrote:
David Olofson wrote:
The SDLK_* symbols are to be considered portable “scancodes”, and have
nothing much to do with ASCII. Each symbol is supposed to represent a
physical key on the keyboard, pretty much disregarding whatever might
be printed on the keycap. Use these when you want a "mega gamepad"
sort of input device.If this is true (and it certainly makes sense, IMHO, as otherwise there
would be no portable way of doing mapping-by-position as opposed to
mapping-by-generated-character - but I haven’t found it stated clearly
anywhere in the documentation), then the current (CVS) implementation on
Mac OS X is wrong.When I press the middle key in the second row (it’s labeled “Z” on my
Swiss German keyboard), I get either SDLK_z or SDLK_y depending on
whether I use a Swiss German or US keyboard mapping, while I should get
the same code in both cases (I guess it should be SDLK_y, assuming that
the SDLK_* codes are based on a US keyboard).I could probably look into fixing this when I have time, but that won’t
be in the next few weeks.-Christian
Hello
Linux has the same problem. I use US-International in an US keyboard to make
special letters in spanish. The ~ and ’ keys give me unknown key if i use
US-International, but if i change it to US it gives me the correct key. So i
think it doesnt give the physical key in the keyboard.
Bye—
Alejandro Arrieta Rios
Ms Cs Student UTFSM
Bs Computer Science UTFSM
Chile