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

From ScummVM :: Wiki
Jump to navigation Jump to search
Line 120: Line 120:
* virtual const Common::KeyState *getMappingKey(const Common::UserAction);
* 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 to https://sourceforge.net/tracker/download.php?group_id=37116&atid=418822&file_id=238998&aid=1752243

Revision as of 22:05, 30 July 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 to https://sourceforge.net/tracker/download.php?group_id=37116&atid=418822&file_id=238998&aid=1752243