-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use ScanCodes instead of KeyCodes for Keyboard mapping #8032
base: develop
Are you sure you want to change the base?
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.Z
andKeys.Q
in theFR
keyboard 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
US
layout (it also already included onlyUS
keys, so that shouldn't be much of an issue I assume).Meaning, although you are pressing
^
on theDE
keyboard, it is detected asKeys.OemTilde
(~
)Meaning, although you are pressing
ö
on theDE
keyboard, it is detected asKeys.OemSemicolon
(;
)You get the idea