Difference between revisions of "Keymapper"

Jump to navigation Jump to search
3 bytes removed ,  15:12, 1 February 2020
m
Formatting
(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:
: Example when reusing the existing input handling:


<syntaxhighlight lang="cpp">
<syntaxhighlight lang="cpp">
Line 57: Line 57:




:: Example when using custom engine actions:
: 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.
: 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.  
53

edits

Navigation menu