Skip to content
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

Key mapping problems on non-US keyboard layouts #1266

Open
rversteegen opened this issue Dec 6, 2023 · 0 comments
Open

Key mapping problems on non-US keyboard layouts #1266

rversteegen opened this issue Dec 6, 2023 · 0 comments
Labels
bug Yeah... that's broken controls Keyboard, mouse and joystick/gamepad input/controls editor UI User interface issues; use "menus" for in-game UI gfx_sdl2 Specific to the SDL 2 graphics/IO backend

Comments

@rversteegen
Copy link
Contributor

Refiling this issue to start afresh, replacing #785 which is entirely obsolete and irrelevant discussion.

Although text entry should work, key mapping for key combos can still be quite broken. A specific example is pressing + to e.g. add a slice or a map layer: on a German keyboard using gfx_sdl2 you have to press the ´ key (left of backspace, where + is on a US keyboard), or press numpad +.

Aside from mappings, we also make incorrect assumptions about which symbols share keys or not. The < > [ ] { } , . keys are the biggest problems. E.g. on a German keyboard < and > are on the same key, a key that doesn't even exist on a US keyboard! So if we respected the actual keycaps for the user's layout they might have to press Shift/Alt/Fn to access some keys. That's a change we might want to make just in Custom, not Game. Although I'd struggle to find any games that'd be affected. Maybe a couple of roguelikes that use the ? key?

The ability for users to remap controls in Custom would be very nice and would let people replace awkward controls like having to press Shift-< to input > to e.g. change palette colour, but that's a separate feature. Key combos should just work, pressing Shift/Alt/Fn as needed, without having to remap anything.

Part of this problem is gfx_sdl2 specific (I haven't tested the others yet): gfx_sdl uses the key-symbol-based SDLKey while gfx_sdl2 uses the key-location-based SDL_Scancode, and I don't remember why I made that change, maybe because I thought it was closer to the behaviour of QB and FB or maybe because it caused mapping problems when holding Shift? It's likely gfx_sdl2 should switch to using SDL_Keycode but doing so might break other things.

SDL2's SDL_keysym included in key events provides the SDL_Scancode (SDL_SCANCODE_* constants), which tells the physical location on the keyboard with reference to a US keyboard layout, and the SDL_Keycode (SDLK_* constants). In many cases the SDL_Keycode is equal to the non-decomposed unicode character for that key. SDL 1.2 is bit different. SDL 1.2's SDL_keysym has the raw 8-bit scancode (no constants provided), the virtual SDLKey sym (SDLK_* constants), and the corresponding unicode character.

@rversteegen rversteegen added bug Yeah... that's broken controls Keyboard, mouse and joystick/gamepad input/controls gfx_sdl2 Specific to the SDL 2 graphics/IO backend editor UI User interface issues; use "menus" for in-game UI labels Dec 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Yeah... that's broken controls Keyboard, mouse and joystick/gamepad input/controls editor UI User interface issues; use "menus" for in-game UI gfx_sdl2 Specific to the SDL 2 graphics/IO backend
Projects
None yet
Development

No branches or pull requests

1 participant