53
edits
Difference between revisions of "Keymapper"
Jump to navigation
Jump to search
m
wording
m (remove an obsolete todo) |
m (wording) |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 42: | Line 42: | ||
while (_system->getEventManager()->pollEvent(event)) { | while (_system->getEventManager()->pollEvent(event)) { | ||
switch (event.type) { | switch (event.type) { | ||
case Common::EVENT_KEYDOWN: | |||
switch (event.kbd.keycode) { | |||
case Common::KEYCODE_t: | |||
doTalk(); | |||
break; | |||
case Common::KEYCODE_u: | |||
doUse(); | |||
break; | |||
} | |||
} | } | ||
} | } | ||
| Line 89: | Line 89: | ||
while (_system->getEventManager()->pollEvent(event)) { | while (_system->getEventManager()->pollEvent(event)) { | ||
switch (event.type) { | switch (event.type) { | ||
case Common::EVENT_CUSTOM_ENGINE_ACTION_START: | |||
switch ((MyEngineAction)event.customType) { | |||
case kMyActionTalk: | |||
doTalk(); | |||
break; | |||
case kMyActionUse: | |||
doUse(); | |||
break; | |||
} | |||
} | } | ||
} | } | ||
| Line 107: | Line 107: | ||
* Keymaps can be situational, thus engines may define multiple keymaps. Keymaps can be enabled / disabled at any time to select which actions are relevant for the current situation. For example for a RPG game there may be one keymap for the overworld, one for combat and one for shops. | * Keymaps can be situational, thus engines may define multiple keymaps. Keymaps can be enabled / disabled at any time to select which actions are relevant for the current situation. For example for a RPG game there may be one keymap for the overworld, one for combat and one for shops. | ||
* Text input needs special care in conjunction with the keymapper. Given that keys can be remapped, players may want to remap, for example, the arrow keys to WSAD. But then when text input is required, it is no longer possible to type those letters because they map to the arrow keys. The solution to this issue is to disable the keymap that handles key shortcuts while a text input widget is focused. | * Text input needs special care in conjunction with the keymapper. Given that keys can be remapped, players may want to remap, for example, the arrow keys to WSAD. But then when text input is required, it is no longer possible to type those letters because they map to the arrow keys. The solution to this issue is to disable the keymap that handles key shortcuts while a text input widget is focused. | ||
* Keep in mind that some ports may not have a keyboard and mouse. The default input mapping should include mapping for game controllers. | |||
== 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. | |||