The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Hi,

on AZERTY Keyboards (used at least in France and Belgium), the first row
of keys is not ^, 1, 2, 3, 4, .. or similar but ², &, é, ", ', (, -, è,
_, ç, à, ), =. (The numbers are reached with Shift).
There are other variants of AZERTY (eg in Belgium) which are slightly
different. See https://en.wikipedia.org/wiki/AZERTY

For those keys, the SDL_Keycode values on Linux/X11 seem to be 231 (ç),
232 (è) etc - what's that, extended ASCII values or something?
Whatever it is, it's no defined SDL_Keycode (SDLK_*) constant (they go
up to 126 aka 'z' and then go on with really big numbers from
SDL_SCANCODE_TO_KEYCODE()).
And on Windows the keycodes are even different - there you'll apparently
get the ones you'd get on a QWERTY keyboard (for the number keys).
(No idea about OSX or Wayland etc).

I guess we should have nice named constants for all those keys that are
guaranteed to be consistent between operating systems.

In https://github.com/dhewm/dhewm3/pull/135 there is a little additional
information and discussion on how to handle those keys.

Cheers,
Daniel
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Dnia 2 Listopada 2015, 23:15, Pn, Daniel Gibson napisa³:

Those two match ISO 8859-1.

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Am 04.11.2015 um 01:33 schrieb "Micha³ Bieliñski":

Ok, so my guess wasn't far from the truth :)

I'm a bit surprised that there are no other reactions to my post.
Does no one actually use AZERTY layouts?

Or do consistent SDL_Keycodes just not matter to most people?
That'd be really surprising to me, because in my experience when porting
games it's not uncommon to map SDLK_* constants to some
game/engine-internal constants for key bindings etc - this does not work
with AZERTY keyboards right now (at least not in a portable way and
without hardcoding numbers that have no associated SDLK_* constant)

Cheers,
Daniel
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2015-11-11 14:50 GMT-03:00, Daniel Gibson:

I think the problem here is mixing up keycodes with scancodes. The
former try to match the key labels, the latter try to match the
physical position of the keys (so to get the first six letters of the
top row, you're looking for the scancodes of the Q W E R T Y keys,
which do indeed map to A Z E R T Y on AZERTY keyboards).

If you really need to, SDL_GetKeyFromScancode will convert a scancode
into a keycode. In fact this is what Sol does in order to show the
correct letters in the keyboard settings despite internally using
scancodes.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Just noticed the first post of the thread went to the spam folder (yay
mailing list!). Still the point should stand, keycodes map to the
labels, scancodes to the positions, and it's a problem only if SDL
can't map those properly within those rules.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 11/11/2015 07:02 PM, Sik the hedgehog wrote:

Uhh, that may explain things.. did GMail tell you why it considered my
mail spam? (WTF GMail, I sent that mail via your own servers!)


(For the sake of completeness, from your other mail, my combined reply
is below:)


Sorry, I'm unsure I get your point.
I was talking about Keycodes (not Scancodes) all the time. The first row
of keys on AZERTY-keyboards (the ones with 1,2,... on QWERTY) seem to
generate the expected Scancodes, but invalid Keycodes on Linux and
the SDL_Keycodes for 1,2,... on Windows.
I don't know what SDL_GetKeyFromScancode() generates for the Scancodes
(I should probably try to find that out), but it should really be
possible to use the Keycodes directly.

I'm aware that using Scancodes internally is a good idea, but if you're
porting a game or engine that doesn't already do that, it's a lot of
work.. e.g. Doom3BFG uses DirectInput DIK_* Scancodes internally, so it
works great, I just had to map SDL2 Scancodes to DI scancodes[1] and
write a function to to provide the right labels for the menu.
Other games like the original Doom3 or Quake2 however use keycodes
internally - they have their own constants for them and to display keys
in the menu etc they have a static mapping of those keycode to strings.
So in that case it really is easiest to translate SDLK_* to the
game-internal Keycodes, without using Scancodes at all.
And of course there's also the SDL1.2 backwards compatibility thing, but
this is becoming less and less relevant.

Cheers,
Daniel

[1] If anyone else has to do that mapping, the following should help:
https://github.com/DanielGibson/Snippets/blob/master/sdl2_scancode_to_dinput.h
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Seems like OSX behaves the same as Linux and I'm not the only one
noticing this, see https://forums.libsdl.org/viewtopic.php?t=11573

On 11/02/2015 11:15 PM, Daniel Gibson wrote:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I reported this in bugzilla so it isn't lost, see
https://bugzilla.libsdl.org/show_bug.cgi?id=3188

Cheers,
Daniel

On 11/14/2015 08:11 PM, Daniel Gibson wrote:

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

By the way, my workaround (in dhewm3[1] and Yamagi Quake II[2]) is to
check the key events' scancodes if they're >= SDL_SCANCODE_1 and <=
SDL_SCANCODE_0 and map those to the 1, 2, ..., 9, 0 keys.
So I ignore the SDL_Keycode for those keys and pretend that they're
always the number keys like on QWERTY.
A quick research suggests that those keys are always either numbers or
have the corresponding numbers reachable via shift (like on AZERTY),
even for more obscure layouts like DVORAK or Neo.
So I guess this behavior shouldn't be too surprising for anyone and thus
tolerable.

Maybe SDL could even do the same (as it seems to do on Win32 already).

Cheers,
Daniel

[1]
https://github.com/yquake2/yquake2/commit/5863beafdec19f8f207c543837e2006ca7f321c6
[2]
https://github.com/dhewm/dhewm3/commit/c5ad45368ad49baaa711ea2e7bd0050f40a68317
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org