53
edits
Difference between revisions of "Keymapper"
m
wording
(→For engine developers: Mention game controller mapping requirements) |
m (wording) |
||
| Line 110: | Line 110: | ||
== For backend developers == | == For backend developers == | ||
* To define the available input devices, a backend | * To define the available input devices, a backend needs to implement '''OSystem::getHardwareInputSet'''. The declared input devices must match the events that are produced by the backend in reaction to user input. It's best not to have any hardcoded button mapping in the backend. For example in the case of a game console with solely a gamepad as input device, when the player presses a button, the backend should send ''EVENT_JOYBUTTON_{DOWN,UP}'' events, not ''EVENT_LBUTTON{DOWN,UP}''. The keymapper will do the transformation from joystick events to mouse events if necessary. | ||
* Backends can define (or replace) default bindings for any keymap. To do so, implement '''OSystem::getKeymapperDefaultBindings'''. This can be used to make room in the default keymaps for backend specific actions, or to provide better defaults for the platform than those defined in the keymap. | * Backends can define (or replace) default bindings for any keymap. To do so, implement '''OSystem::getKeymapperDefaultBindings'''. This can be used to make room in the default keymaps for backend specific actions, or to provide better defaults for the platform than those defined in the keymap. | ||
* Backends can | * Backends can define keymaps to allow players to remap the backend specific features. To do so, implement '''OSystem::getGlobalKeymaps'''. When implementing backend specific keymaps, it's best to request ''EVENT_CUSTOM_BACKEND_ACTION_{START,END}'' events in response to the user input. During event handling, ''Event::customType'' is used to recognize the action that needs to be executed. | ||
== TODO == | == TODO == | ||
* Consider adding support for joystick button combos | * Consider adding support for joystick button combos | ||
* Rework the way keyboard input is mapped to actions. Match only on the keycode and then filter on the modifiers to handle partial matches. Besides keep a list of currently started actions. When receiving a key up event, check if an end event needs to be emitted for one of the started actions ignoring the modifiers (to handle the case where the user stops pressing the modifier keys first). Additionally filter the emitted actions based on the list of currently started actions to prevent an action from being started twice at the same time by two different inputs. | * Rework the way keyboard input is mapped to actions. Match only on the keycode and then filter on the modifiers to handle partial matches. Besides keep a list of currently started actions. When receiving a key up event, check if an end event needs to be emitted for one of the started actions ignoring the modifiers (to handle the case where the user stops pressing the modifier keys first). Additionally filter the emitted actions based on the list of currently started actions to prevent an action from being started twice at the same time by two different inputs. | ||