Use ScanCodes instead of KeyCodes for Keyboard mapping #8032
Conversation
|
The problem with your PR is that scan-codes vary per keyboard layout. In the DE keyboard Z = English Keyboard Q. The scancodes are the same. This is a discrepancy is normally resolved via the OS; SDL simply passes the scan-codes, ignorant of the keyboard layout. This PR breaks the existing system in 2 ways: It breaks existing keyboard mappings, and loses the ASCII mapping. |
To quote yourself 😄
The scancodes stay the same, regardless of keyboard layout. It's the keycodes that change with the keyboard layouts.
It doesn't break the US keyboard layout, which is the only one that works properly. Maybe it would be better to offer the ScanCode functionality in addition to the existing KeyCode mapping? |
|
Has there been any consideration towards merging this PR? It seems like a straight upgrade, assuming that Sdl accurately reports scancodes accross desktop platforms. The way I see it (again assuming that it works as intended), it will have no negative impact on the current standard US layout, but it will provide a better default behaviour for non-US layouts. |
|
This solution is incomplete to me. Yes, most libraries made that choice, but Unity does offer an API to get what's actually printed on the physical key depending on the user's layout. Which we don't (and it's a concern whenever you want to display key bindings in a setting menu, for example). The initial XNA design (and SDL's virtual keys) was to try to fuse those concerns into a single bloat-free API: you get what you expect. It indeed came with a very US-centric view on the problem, but the intent was good to me and I believe that we can still expand on that and be smarter about it to support a wider range of keys. Anyway, as-is it's a breaking change and can't be considered for the ongoing 3.8 branch. |
Fixes the issue described in #8033
US keyboard layout should be unaffected by this.
DE keyboard layouts would now be able to use more keys (
^ ß ´ ü ö ä #).Similar for other keyboard layouts like
FR.Keys.W and Keys.A would now map to
Keys.ZandKeys.Qin theFRkeyboard layout.So if you map your walking to WASD via the Keys enum, then players with FR layout will be able to walk with ZQSD - which is the preferred way.
This also means that the Keys enum is only representative for the
USlayout (it also already included onlyUSkeys, so that shouldn't be much of an issue I assume).Meaning, although you are pressing
^on theDEkeyboard, it is detected asKeys.OemTilde(~)Meaning, although you are pressing
öon theDEkeyboard, it is detected asKeys.OemSemicolon(;)You get the idea