69
edits
(key mapper dialog features, edit game dialog, mappings saving/loading) |
|||
(3 intermediate revisions by the same user not shown) | |||
Line 127: | Line 127: | ||
== 2007-07-31 (Tuesday) - key mapper dialog features, edit game dialog, mappings saving/loading == | == 2007-07-31 (Tuesday) - key mapper dialog features, edit game dialog, mappings saving/loading == | ||
First of all, here are is the list of features which the key mapper dialog should support: | First of all, here are is the list of features which the key mapper dialog should support: | ||
1) ability to see all current key/action mappings; | |||
2) possibility to completely unassign key from some particular action; | |||
3) checks for the same key being assigned to different actions; | |||
4) there should be a way to define the engine and game actions (like in game data files, etc.); | |||
5) action mapping priorities (if there is no mapping for these actions the game won't start or smth like this. The situation when actions with lower priority have mappings while the actions with higher priority don't won't be allowed.) | |||
6) more then one keymap (as for Indy games); | |||
7) mappings should be displayed in two modes: action -> key(s) and key -> action (this is rather an improvement) | |||
Today I have implemented the saving and loading of action mappings to and from the scummvm config file. I have also added the new key mapper tab to the edit game dialog with the buttons and action list. I have also thought over most of the implementation details for the above mentioned features. | Today I have implemented the saving and loading of action mappings to and from the scummvm config file. I have also added the new key mapper tab to the edit game dialog with the buttons and action list. I have also thought over most of the implementation details for the above mentioned features. | ||
== 2007-08-01 (Wednesday) - working on key mapper features listed above == | |||
Today I have cleared the 2nd and 3rd point from the requirements list, in course of that work no. 7 was also partially cleared. I have been actively working on No. 1 today. Item 5 is not big and will be implemented in the course of work on no. 1. With regards to no. 4, I have fixed key mappings save/load functionality to save the mappings under the specific game domains. | |||
== 2007-08-02 (Thursday) - discussion with SEV on points no. 4 and 6 from the key mapper features list, reinstalling the software == | |||
Today I have talked to SEV about the place where to define the engine and game actions. They will be defined in the game data files and retrieved using common/advancedDetector.cpp static void updateGameDescriptor(). The key maps storing algorithm is as follows: | |||
* in order to save a mapping we need to store a key and an action; | |||
* to store a key it's enough to store its keycode and the flags; | |||
* so it's a 6 digit hexadecimal number; | |||
* an action could also be identified by it's default key; | |||
* so it's another 6 digit hexadecimal number; | |||
* this approach is compact and we can save all mapping in one string, and then easily parse it, since we have the fixed length for all elements (I got the idea for it from gui/Action.h save/loadMapping functions); | |||
* this string is then saved under [scummvm] for global mappings; | |||
* and under say [sky] for game mappings; | |||
* actions with identical default keys are dissalowed within single game. | |||
Here are the SEV's comments regarding the key map sets (for Indiana Jones fighting, i.e.): | |||
I recommend to show those sets on tabs in keymapper dialog: it's simple to implement and will not clobber your output. In 90% of cases there will be a single set but rest 10% belong to quite important set of games: | |||
* indiana jones -> fighting | |||
* gobliiins -> password entry | |||
There also should be way to disable all mappings temporarily, say, when user uses predictive dialog. |
edits