1,554
edits
Difference between revisions of "Keymapping Improvements"
Jump to navigation
Jump to search
Rant on mapper
m (Keymapping improvements moved to Keymapping Improvements: capitalization) |
(Rant on mapper) |
||
| Line 73: | Line 73: | ||
backends, will make user friendly key mapping dialog(s) possible, and | backends, will make user friendly key mapping dialog(s) possible, and | ||
simply make it easier for us to add certain new features. | simply make it easier for us to add certain new features. | ||
=== Eugene's comment on keymapper task === | |||
Current keymapper code could be used as a base, but only in | |||
terms of initial GUI. In other areas it does not suit our needs. What | |||
should be done there is this: | |||
Each engine knows which keys is used by some particular game. I.e. there are | |||
cases when different games supported by same engine require different | |||
set of keys. | |||
Additionally, some games need different keyboard layout at different parts of | |||
the games. Good example is fights in Indy3. | |||
Each backend knows which hardware keys exist on some particular device. And | |||
again, some backends have support devices with different set of keys (WinCE, | |||
Symbian). | |||
Current approach is that in keymapper there are hardcoded gameids and predefined | |||
set of keys. This is really really bad, since no backend code should | |||
know about any | |||
particular game or engine. | |||
Thus, the appoach is this: | |||
# Backend registers with keymapper and provides it list of hardware keys, and their preferred class of action (such as directions, functional keys) | |||
# Game engine registers with keymapper and provides it set of keys which need to be mapped, along with their class, preferred mapping and priority. I.e. some keys are must to be present, and some are completely optional | |||
# Then keymapper aligns these two list in attempt to "autoassign" keys. In most cases it will be based on preferred mapping provided by the engine. | |||
# User can anytime open a dialog and remap any key. This should be stored in our global .ini file on per-game basis | |||
There should be one global mapping, mainly for common keys such as directions, | |||
mouse buttons, exit and save buttons. Again, it has to be editable by the users. | |||
Also as I mentioned, there could be several mappings per game, and engine | |||
provides them all at the game start, so user can alter all of them. | |||
Also engine will notify the keymapper and request some particular map | |||
to be activated. Additionally these keymaps should be possible to switch | |||
both from GUI, or by a special key. | |||