53
edits
(Created page with "=== Keymapper considerations === == Basics == * Backends define what input devices are available and with which characteristics (number of buttons, button names..). * Engines...") |
m (Formatting) |
||
Line 15: | Line 15: | ||
: Example when reusing the existing input handling: | |||
<syntaxhighlight lang="cpp"> | <syntaxhighlight lang="cpp"> | ||
Line 57: | Line 57: | ||
: Example when using custom engine actions: | |||
<syntaxhighlight lang="cpp"> | <syntaxhighlight lang="cpp"> | ||
Line 103: | Line 103: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
: Engines with engine-driven input handing should prefer using custom action events as this approach it is more powerful. Engines where input handling is script-driven probably have no choice but to use the first option. It's up to the engine developer to choose which is the best in each specific context. | |||
* 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. |
edits