Add support for non-ascii input bindings

[DimitriyPS]

I do not know English (use translator). I find it hard to formulate their thoughts in English. If something (in the text below) is unclear or questionable, please give a leading question. I will try to describe more.

I started developing the game "first person" and faced a problem. Godot does not support international keyboard control. That is, the control works only when the English keyboard layout. Or I did not find the opportunity to make the control does not depend on the keyboard layout.

In the window "Projekt Settings", tab "Input Map" - it is not possible to add non-Latin characters. But even if such a possibility was - it did not solve the problem. Languages very much and can't foresee everything.

For a moment hope gave:
class_input
bool is_key_pressed ( int scancode )

(Table scancode: https://github.com/godotengine/godot/wiki/class_@global-scope)

But it is not the keyboard codes are, the codes of entered characters. As a result, all the same error, switching the keyboard layout leads to a complete breakdown of control in the game to Godot.

This is a very serious error for develop international games. The necessary mechanism for scanning the keyboard (key codes), not that it introduces characters.

[Calinou]

(Note: I'm not a C++ programmer, this is just my opinion as a game user and developer)

There are generally two ways to handle input in games:

• the "Windows way": display all keys as QWERTY ones (eg. an AZERTY user presses Z, and sees W in a key configuration dialog),
• the "UNIX way": display all keys as keyboard-layout specific ones (eg. and AZERTY user presses Z, and sees Z in a key configuration dialog).

Each has their upsides and downsides:

• the "Windows way" works on more keyboard layouts than the "UNIX way" does, but it may be confusing to users,
• the "UNIX way" actually shows which key the user has pressed in the configuration dialog, and can thus be much less confusing.

Note: I call it the "UNIX way" because it's generally how input is handled in games on GNU/Linux and BSD, but SDL2 actually behaves like the "Windows way", even on GNU/Linux or BSD. This can be seen in games like Team Fortress 2.

[est31]

@Calinou Or, go the "smart way": display characters by their keyboard layout, and if the keyboard layout changes, let the underlying button stay the same, but the characters displayed change. I know that this works on X11, dunno about other platforms.

[est31]

The current way godot handles this is a bit... bad.

First of all, what the code internally refers to scancode is just wrong. See this link for a terminology overview (lead paragraph is enough), and wikipedia uses scancode for the harware level code as well: wiki page for scancode.

And secondly, yes, unfortunately there is no way to just sit there and listen for key presses of arbitrary scan coes, to find out which key to listen for.

And thirdly, godot should have a way to enable you to listen to raw keycodes (map not applied) too, not just to what godot calls "scancodes".

[reduz]

godot works this way due to long ago relying on SDL

https://www.libsdl.org/release/SDL-1.2.15/docs/html/guideinputkeyboard.html

it should be changed to a single u32 key nowadays, the same way as Qt does.
this might get fixed in the future.

On Sat, Nov 28, 2015 at 6:22 PM, est31 [email protected] wrote:

The current way godot handles this is a bit... bad.

First of all, what the code internally refers to scancode is just wrong.
See this link https://wiki.archlinux.org/index.php/Extra_keyboard_keys
for a terminology overview (lead paragraph is enough), and wikipedia uses
scancode for the harware level code as well: wiki page for scancode
https://en.wikipedia.org/wiki/Scancode.

And secondly, yes, unfortunately there is no way to just sit there and
listen for key presses of arbitrary scan coes, to find out which key to
listen for.

And thirdly, godot should have a way to enable you to listen to raw
keycodes (map not applied) too, not just to what godot calls "scancodes".

—
Reply to this email directly or view it on GitHub
#2915 (comment).

[reduz]

another problem is, as far as I remember, X11 will only give you unicode on
keypress, and many scancodes can lead to a single unicode.

On Sat, Nov 28, 2015 at 6:38 PM, Juan Linietsky [email protected] wrote:

godot works this way due to long ago relying on SDL

https://www.libsdl.org/release/SDL-1.2.15/docs/html/guideinputkeyboard.html

it should be changed to a single u32 key nowadays, the same way as Qt
does. this might get fixed in the future.

On Sat, Nov 28, 2015 at 6:22 PM, est31 [email protected] wrote:

The current way godot handles this is a bit... bad.

First of all, what the code internally refers to scancode is just wrong.
See this link https://wiki.archlinux.org/index.php/Extra_keyboard_keys
for a terminology overview (lead paragraph is enough), and wikipedia uses
scancode for the harware level code as well: wiki page for scancode
https://en.wikipedia.org/wiki/Scancode.

And secondly, yes, unfortunately there is no way to just sit there and
listen for key presses of arbitrary scan coes, to find out which key to
listen for.

And thirdly, godot should have a way to enable you to listen to raw
keycodes (map not applied) too, not just to what godot calls "scancodes".

—
Reply to this email directly or view it on GitHub
#2915 (comment)
.

[est31]

Having a single u32 key includes the problem: which one to take?
E.g. if you press the key "c" on the keyboard, it can either result in "c" or in "C" depending on whether caps lock is on and shift is pressed. Or think of ctrl / alt combinations. Best is to send an event with:

• The key (u32) with all keyboard modifiers
• The key (u32) without all keyboard modifiers
• A list of bools for the specific keyboard modifiers (shift, alt, ctrl, etc) whether they are pressed as well

[DimitriyPS]

Good time of day.

This issue was given the status of a "feature proposal". It's probably not the most urgent task for the developers of Godot. But let me ask:

1. it is included in the existing development plan?
2. can we expect its implementation in the next versions Godot?

[akien-mga]

Fixed by #18020.