User:Seldon/GSoC2007-ProjectDiary
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-08 (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;