Scancodes vs keycodes

SDL Development
1

In SDL 1.3 I introduced the concept of a scancode, which is keyboard mapping
independent.
e.g. WASD with scancodes will always be in an inverted T, while it might be
remapped to different positions using keycodes on a French keyboard or
Dvorak layout.

Unfortunately as you might imagine the scancodes are hardware dependent and
so things are broken on unusual keyboards.

Is anybody using this distinction between scancodes and keycodes in SDL
1.3? Or is it preferrable to go back to just using keycodes the way SDL 1.2
works?

See ya!–
-Sam Lantinga, Founder and CEO, Galaxy Gameworks

2

I’ve found scancodes to be a terrible idea. I had code that worked on Win32
system, reasonably worked on Linux/x86 systems, and went to hell when I ran
it on Solaris/SPARC. Turns out just translating the windowing system
messages into a platform independent message was the best way. While it is
unfortunate that WASD doesn’t always translate depending on keymap, a real
game would allow the user to remap the controls anyways and this would be
done once and problem solved.

PatrickOn Fri, Mar 11, 2011 at 1:26 PM, Sam Lantinga wrote:

In SDL 1.3 I introduced the concept of a scancode, which is keyboard
mapping independent.
e.g. WASD with scancodes will always be in an inverted T, while it might be
remapped to different positions using keycodes on a French keyboard or
Dvorak layout.

Unfortunately as you might imagine the scancodes are hardware dependent and
so things are broken on unusual keyboards.

Is anybody using this distinction between scancodes and keycodes in SDL
1.3? Or is it preferrable to go back to just using keycodes the way SDL 1.2
works?

See ya!

-Sam Lantinga, Founder and CEO, Galaxy Gameworks

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

3

[…]

While it is
unfortunate that WASD doesn’t always translate depending on keymap, a real
game would allow the user to remap the controls anyways and this would be
done once and problem solved.
[…]

+1

There isn’t really any proper way around making it configurable. Not everyone
wants to use WASD either, even if it’s in the “right” place.On Friday 11 March 2011, at 20.52.14, Patrick Baggett <baggett.patrick at gmail.com> wrote:

–
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

4

Having a concept of a key position is actually more relevant in a game than
key label. If I want to use the number bar, I don’t care if the 3 key is
labeled 3 or ", what I’m interested in is the physical position of the key
as that position is meaningful in terms of gameplay. Same goes for WASD.

Having to remap the keys, usually right after the introduction cinematic,
make the game look unprofessional, and it breaks the player’s immersion at
the very beginning of the game.
If you see it that way, scancodes may be broken on some platforms, but most
gameplays are broken on non US keyboards when using keycodes.

There are some solutions to avoid that. The first is to have SDL give us a
portable way to query the keyboard layout. Then we would adapt the default
configuration to that.
Another would be to ask the user either when downloading the game or when
the game starts for the first time. But I believe it’s wrong to rely on the
user.

As for weird keyboards, not much we can do about that, we game developers
have to manually plan for each of those we wish to support manually anyways.

The best solution in my mind would be to remap the weird platforms to a
standard set of scancodes (solaris/sparc, and more). That way the behaviour
described by patrick would be an SDL bug. That way have some overhead
though. But even if it’s not fully portable, please keep the scancodes. My
target platforms are Windows/Linux/Mac, so if it works for those, I’ll take
it !

2011/3/11 Patrick Baggett <baggett.patrick at gmail.com>> I’ve found scancodes to be a terrible idea. I had code that worked on Win32

system, reasonably worked on Linux/x86 systems, and went to hell when I ran
it on Solaris/SPARC. Turns out just translating the windowing system
messages into a platform independent message was the best way. While it is
unfortunate that WASD doesn’t always translate depending on keymap, a real
game would allow the user to remap the controls anyways and this would be
done once and problem solved.

Patrick

On Fri, Mar 11, 2011 at 1:26 PM, Sam Lantinga wrote:

In SDL 1.3 I introduced the concept of a scancode, which is keyboard
mapping independent.
e.g. WASD with scancodes will always be in an inverted T, while it might
be remapped to different positions using keycodes on a French keyboard or
Dvorak layout.

Unfortunately as you might imagine the scancodes are hardware dependent
and so things are broken on unusual keyboards.

Is anybody using this distinction between scancodes and keycodes in SDL
1.3? Or is it preferrable to go back to just using keycodes the way SDL 1.2
works?

See ya!

-Sam Lantinga, Founder and CEO, Galaxy Gameworks

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

5

2011/3/11 Jean-Fran?ois S?v?re

Having a concept of a key position is actually more relevant in a game than
key label. If I want to use the number bar, I don’t care if the 3 key is
labeled 3 or ", what I’m interested in is the physical position of the key
as that position is meaningful in terms of gameplay. Same goes for WASD.

Having to remap the keys, usually right after the introduction cinematic,
make the game look unprofessional, and it breaks the player’s immersion at
the very beginning of the game.
If you see it that way, scancodes may be broken on some platforms, but most
gameplays are broken on non US keyboards when using keycodes.

There are some solutions to avoid that. The first is to have SDL give us a
portable way to query the keyboard layout. Then we would adapt the default
configuration to that.
Another would be to ask the user either when downloading the game or when
the game starts for the first time. But I believe it’s wrong to rely on the
user.

As for weird keyboards, not much we can do about that, we game developers
have to manually plan for each of those we wish to support manually anyways.

The best solution in my mind would be to remap the weird platforms to a
standard set of scancodes (solaris/sparc, and more). That way the behaviour
described by patrick would be an SDL bug. That way have some overhead
though. But even if it’s not fully portable, please keep the scancodes. My
target platforms are Windows/Linux/Mac, so if it works for those, I’ll take
it !

I disagree with pretty much everything you’ve said, but if someone can write
a function like ScancodeForKey(row, col), then more power to them. I don’t
see any X11 or Win32 APIs to do this though. If there are none, then this
leaves your “position based” solution dead in the water and we’re back to
hard-coded scancode which may or may not map the proper position depending
on the keyboard layout/vendor/OS (yes, the same OS can produce different
scancodes for the exact same hardware, usually for the less frequently used
keys, e.g. F11 / scroll lock). I don’t even know how this solution would
work on iOS based devices though.

The map between “weird” platforms and “common” platforms scancodes is just
wrong. My results weren’t a bug, they were a natural result of what I asked
for. Scancodes are just that, integers that uniquely identify a key on a
keyboard. They can and should be arbitrary values depending on
platform/layout. Easiest example of platform specific scancode conversion
failing: Solaris – plug in a standard USB keyboard in addition to the Sun
keyboard – boom all of your scancodes are wrong. This sort of hell is why
events and messages happen with symbolic constants that contain TRANSLATED
scancode values. Don’t fight it, just love it.

Patrick

6

I don’t understand Patrick, what you’re saying is that it’s difficult, but I
believe Sam is saying that scancodes in 1.3 are already designed as position
indicators. The question is whether or not it makes sense, it’s whether or
not it’s usefull. I had no idea 1.3 had revised the scancode concept, but
should Sam choose to keep it, I’ll definitely use it.
As for the problem with solaris and other OS, just document the cases/OS
that don’t work. If you only target platforms that work, it’s a usefull
feature.

2011/3/11 Patrick Baggett <baggett.patrick at gmail.com>>

2011/3/11 Jean-Fran?ois S?v?re <@Jean-Francois_Severe>

Having a concept of a key position is actually more relevant in a game than

key label. If I want to use the number bar, I don’t care if the 3 key is
labeled 3 or ", what I’m interested in is the physical position of the key
as that position is meaningful in terms of gameplay. Same goes for WASD.

Having to remap the keys, usually right after the introduction cinematic,
make the game look unprofessional, and it breaks the player’s immersion at
the very beginning of the game.
If you see it that way, scancodes may be broken on some platforms, but
most gameplays are broken on non US keyboards when using keycodes.

There are some solutions to avoid that. The first is to have SDL give us a
portable way to query the keyboard layout. Then we would adapt the default
configuration to that.
Another would be to ask the user either when downloading the game or when
the game starts for the first time. But I believe it’s wrong to rely on the
user.

As for weird keyboards, not much we can do about that, we game developers
have to manually plan for each of those we wish to support manually anyways.

The best solution in my mind would be to remap the weird platforms to a
standard set of scancodes (solaris/sparc, and more). That way the behaviour
described by patrick would be an SDL bug. That way have some overhead
though. But even if it’s not fully portable, please keep the scancodes. My
target platforms are Windows/Linux/Mac, so if it works for those, I’ll take
it !

I disagree with pretty much everything you’ve said, but if someone can
write a function like ScancodeForKey(row, col), then more power to them. I
don’t see any X11 or Win32 APIs to do this though. If there are none, then
this leaves your “position based” solution dead in the water and we’re back
to hard-coded scancode which may or may not map the proper position
depending on the keyboard layout/vendor/OS (yes, the same OS can produce
different scancodes for the exact same hardware, usually for the less
frequently used keys, e.g. F11 / scroll lock). I don’t even know how this
solution would work on iOS based devices though.

The map between “weird” platforms and “common” platforms scancodes is just
wrong. My results weren’t a bug, they were a natural result of what I asked
for. Scancodes are just that, integers that uniquely identify a key on a
keyboard. They can and should be arbitrary values depending on
platform/layout. Easiest example of platform specific scancode conversion
failing: Solaris – plug in a standard USB keyboard in addition to the Sun
keyboard – boom all of your scancodes are wrong. This sort of hell is why
events and messages happen with symbolic constants that contain TRANSLATED
scancode values. Don’t fight it, just love it.

Patrick

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

7

I’m using it. It’s my main reason for using SDL 1.3 instead of sticking
to SDL 1.2.On 3/11/2011 12:26, Sam Lantinga wrote:

Is anybody using this distinction between scancodes and keycodes in SDL
1.3? Or is it preferrable to go back to just using keycodes the way SDL 1.2
works?

–
Rainer Deyke - rainerd at eldwood.com