Difference between revisions of "User:Seldon/GSoC2007-ProjectDiary"

Latest revision as of 09:04, 3 August 2007

2007-06-09 (Saturday) - analyzing current backend code

Today I am starting my Small Devices Backend project diary. Here I'll be posting all of the current progress information.

I have already ran a pocketSCUMM port on ACER n311 pocket PC. Now I am analyzing the current backend code.

2007-07-01 (Sunday) - back

I am finally back to the project after a prolonged exams period at the two Universities I am currently studying, and planning to catch with all the work on backends.

I have talked to _sev: we've successfully resolved some linker errors over the TightVNC - all that had to be done is to change the order of library paths. Funny. So, the most important tasks for right now are:

come up with the description of current backends implementation;
study the new idea of events to replace engine specific keymapping code in the backends ( [Scummvm-devel] RFC: Flexible keymapping via new EVENT_ (post 0.10) by Max)

2007-07-03 (Tuesday) - current backend architecture

Yesterday and today I went through all backend implementations (classes that extend OSystem). I gathered the information about all methods in OSystem class hierarchy and presented it the form of tables. There one can easily see all of the OSystem virtual functions, their overriding counterparts in backend implementations, as well backend specific functions. Based on this information it is easy to see what are the common methods for all backends, which of them are simply duplicated, etc.

2007-07-06 (Friday) - functionality

Yesterday and the day before yesterday I have finished reviewing the backends code and uploaded last of the tables in the previous post. Today I've been looking through backends from the perspective of functional features that relate to my project.

Feature	Backend	Osystem child
virtual keyboard	DC(softkbd.h), DS(touchkeyboard.h), wince(PanelKeyboard.h)
keymapper		gp2x, sdl, wince, symbian, ds, palm
downscaler	MorphOS(morphos_scaler.h), wince(CEScaler.h)	DC, gp2x, palm(calc_scale), sdl
upscaler	MorphOS(morphos_scaler.h), wince(CEScaler.h)	DC, gp2x, palm(calc_scale), sdl
predictive input	DS(wordcompletion.h)	DS(addAutoComplete)
zoning		wince, symbian
splash screen	gp32(gfx_splash.h)

2007-07-08 (Sunday) - key mapping

Now, that I've been looking through the backends implementation for a couple of days, I got a pretty good understanding of how they work. I am ready to start implementing my tasks on backends' refactoring. So, as agreed with sev, the first feature to be implemented is key mapping. Yesterday and today I was closely reviewing the current implementation of key mapping. So, key mapping is used to convert key codes to other key codes which in turn are mapped to certain game actions. Key mapping takes place in the pollEvent functions of the backend OSystem classes. The actual device specific mapping is done through the Actions classes like CEActionsSmartphone. Currently only wince supports user key mapping dialogs. In general key mapping is implemeted in wince, symbian, ds, and palm backends. Wince and symbian provide the best implementations.

2007-07-09 (Monday) - new key mapping architecture

Today I had a long conversation with sev on the phone. We have decided that the best idea would be to extend and implement the Max's proposal on Keymapping Improvements. Here is the plan:

according to Max, we introduce new type of events called UserActions;
UserActions represent engine specific actions like quit, pause, etc., and game specific actions like move left, right, jump, etc.
each backend has its own event manager which is aware of all device buttons;
each engine provides the event manager with all the actions it and the currently selected game needs;
event managers are responsible for mapping the key codes to specific actions (there are default and custom/user mappings);
the event manager's pollEvent function will now return the UserAction (it will also fill the event structure for the time being for backwards compatibility)
UserAction class will still have the keyCode field because some engines do check key codes to do smth and some engines also require user text input;

2007-07-11 (Wednesday) - first patch

Today I have created my first backend lib patch! This patch is dealing with the new key mapping architecture. I have added the buttons.h which similar to keyboard.h but also includes codes for mouse buttons. EventManager class has been modified, and the GenericEventManager was added to provide a base class for specific backend event managers' implementations.

2007-07-12 (Thursday) - -devel discussion

Today I have posted a new reply to [Scummvm-devel] RFC: Flexible keymapping via new EVENT_ (post 0.10) with a detailed description of proposed key mapping implementation.

2007-07-13 (Friday) - improved key mapping architecture

Taking into consideration Max's comments to my -devel post, I made some changes to the key mapping design. The main improvement is that we get rid of enum with all action types, replacing it with a key to key mapping. This way we don't have to change the engines' code at all, and plus we provide a nice place to integrate a virtual keyboard (see my replies to [Scummvm-devel] RFC: Flexible keymapping via new EVENT_ (post 0.10) -devel discussion).

2007-07-14 (Saturday) - coding :)

I've been coding all day today. As a result we have OSystem_Common, a base class for all backends' OSystem classes, which provides hooks for key mapper and virtual keyboard. I have also created a KeyMapper class which already knows how to provide a default key mapping functionality. What still needs to be done is the custom mapping (key dialogs, basically). I've also added a virtual keyboard stub, modified the DefaultEventManager and the sky engine to make use of key mapping. You can check out the patch at http://sourceforge.net/tracker/index.php?func=detail&aid=1752243&group_id=37116&atid=418822, patch v3).

2007-07-15 (Sunday) - refactoring

Max revied my code and I did some refactoring afterwards: - removed OSystem_Common in favour for a modularised approach - removed getAvailableKeys() in KeyMapper class - hooked up key mapper and virtual keyboard in default event manager

2007-07-16 (Monday) - refactoring

Replaced the STL in key mapping patch with Common::List and Common::HashMap, added doxygen comments.

2007-07-21 (Saturday) - compilation error fix

I have finally fixed the compilation error in engines/sky/debug.cpp. Unfortunately I did not have the internet connection to see that it was fixed already by wjpalenstijn.

2007-07-24 (Tuesday) - basic key mapper dialog added

I have used the gui/KeysDialog.h and modified it to work with the KeyMapper implementation.

2007-07-28 (Saturday) - key mapper refactoring

I have refactored KeyMapper to better fit key mapper dialog implementation. The new methods are:

virtual void addActionMapping(const Common::KeyState, const Common::UserAction);
virtual void addActionMappings(const Common::ActionList);
virtual void clearActionMappings();
virtual const Common::KeyState *getMappingKey(const Common::UserAction);

I have also fixed the key mapper dialog to make use of these new methods and uploaded the patch v4.1 to https://sourceforge.net/tracker/download.php?group_id=37116&atid=418822&file_id=238998&aid=1752243

2007-07-30 (Monday) - patch fix, key mapper dialog features, GUI

Today I have fixed my v4.1 patch: added required includes for the kyra engine, fixed the common/event-manager.h include and the non-virtual destructor warnings. Started implementing the mappings save and load functionality in KeyMapper class. Talked to sev regarding the key mapper dialog features. I'll post them here once he reviews my comments. I have also figured out how to modify GUI windows and their elements in themes *.ini files.

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: 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.

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.

@@ Line 120: / Line 120: @@
 * virtual const Common::KeyState *getMappingKey(const Common::UserAction);
-Fixed the key mapper dialog to make use of these new methods.
+I have also fixed the key mapper dialog to make use of these new methods and uploaded the patch v4.1 to https://sourceforge.net/tracker/download.php?group_id=37116&atid=418822&file_id=238998&aid=1752243
+== 2007-07-30 (Monday) - patch fix, key mapper dialog features, GUI ==
+Today I have fixed my v4.1 patch: added required includes for the kyra engine, fixed the common/event-manager.h include and the non-virtual destructor warnings. Started implementing the mappings save and load functionality in KeyMapper class. Talked to sev regarding the key mapper dialog features. I'll post them here once he reviews my comments. I have also figured out how to modify GUI windows and their elements in themes *.ini files.
+== 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:
+) ability to see all current key/action mappings;
+) possibility to completely unassign key from some particular action;
+) checks for the same key being assigned to different actions;
+) there should be a way to define the engine and game actions (like in game data files, etc.);
+) 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.)
+) more then one keymap (as for Indy games);
+) 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.
+== 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.