W" means up; and so other bindings such as Z and X must also be physical to avoid clashing. However this means the labels are wrong for QWERTZ and AZERTY keyboards: | Action | QWERTY | QWERTZ | AZERTY | | ------ | ------ | ------ | ------ | | Up | W | W | Z | | Left | A | A | Q | | Down | S | S | S | | Right | D | D | D | | Throw | X | X | X | | Repel | Z | Y | W | We don't actually show WASD in the UI, but we do show Z for Repel (for example). Rather than hardcoding that the glyph for Repel is Z on a keyboard and L1 on a gamepad, instead look these up dynamically. Update to Kenney Input Prompts 1.5, carrying forward the change from commit c17ffac to remove the solid grey region in the top-right of the keyboard-and-mouse atlas. Apply the same change to the joypad spritesheets: the Switch stick glyphs would have the same problem, but we've never tested them! Among other things, this update introduces a glyph for the "Pause" key on a keyboard, which we do actually have a binding for (though it's not the primary so is not shown). Only check in the five atlases sheets that we actually use – keyboard, switch, steamdeck, xbox, playstation – along with the accompanying XML file. Change the button resources to be based on the `Key`/`JoyButton`/etc. enums. Rewrite the importer accordingly to generate just one resource per device type (which contains all the necessary `AtlasTexture`s) rather than hundreds of separate `AtlasTexture` resources. (It was my idea to do the latter; I was wrong!) Then in the input hint controls, determine which key/button the event is bound to, and display that. In theory this will mean that we never have to manually look up the glyphs for a new action again: interact_input.gd will do that for us. On the web, `DisplayServer.keyboard_get_keycode_from_physical()` is not implemented: it is not possible to ask the browser for the logical keycode corresponding to a physical keycode. So on the web platform we always show 'Z' even on an AZERTY keyboard where it should be 'W'. A bit sad but not a regression. There is a web API for this, but it is not widely supported, is blocked in some browsers for anti-fingerprinting reasons, and Godot doesn't (yet) know how to use it. https://developer.mozilla.org/en-US/docs/Web/API/Keyboard/getLayoutMap I considered working around this limitation, either by calling `getLayoutMap` directly, or by inferring the keyboard layout based on the events we actually receive: i.e. if we receive an InputEventKey whose keycode is 'z' but physical keycode is 'w', we can infer that the layout is almost certainly AZERTY. This does work – which makes me think that Brave blocking `getLayoutMap()` is probably not improving user privacy! – but I don't think it's worth the complexity. There are some other annoying edge cases to handle, including: - R2 is analogue so is represented in Godot as an axis that can never be negative, but we present it as a button. - The arrow keys want to be treated like a joystick in the UI. - We show mouse + keyboard controls for some actions, so we need to keep the keyboard vs mouse branching. - Sony helpfully relabelled the Start/Select buttons from PS3 (and older) to something else in PS4 and something else again in PS5. I chose the PS5 glyphs because they don't have any text on them. If we wanted to fix this in future, we could ask InputHelper for the "granular" identifier for the joypad and handle the three PlayStation generations separately. Resolves #2185

Commits

Commits on Jun 11, 2026

Input hints: Display logical keys