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

From ScummVM :: Wiki
Jump to navigation Jump to search
 
(40 intermediate revisions by 2 users not shown)
Line 14: Line 14:
* 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)
* 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 arhitecture ==
== 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.
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.


Legend:
* [[User:Seldon/DreamCast Backend|DreamCast]]
* [[User:Seldon/DS Backend|DS]]
* [[User:Seldon/GP2X Backend|GP2X]]
* [[User:Seldon/GP32 Backend|GP32]]
* [[User:Seldon/MorphOS Backend|MorphOS]]
* [[User:Seldon/Palm Backend|Palm]]
* [[User:Seldon/PS2 Backend|PS2]]
* [[User:Seldon/PSP Backend|PSP]]
* [[User:Seldon/SDL Backend|SDL]]
* [[User:Seldon/X11 Backend|X11]]


{|  x:str border=0 cellpadding=0 cellspacing=0 width=888 class=xl2515771 style='border-collapse:collapse;table-layout:fixed;width:666pt'
== 2007-07-06 (Friday) - functionality ==
|- class=xl2915771 height=18 style='height:13.5pt'
 
|  height=18 class=xl3015771 width=444 style='height:13.5pt;width:333pt' | OSystem
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.
|  class=xl3115771 width=444 style='border-left:none;width:333pt' | OSystem_Dreamcast
 
: public OSystem
 
|-  height=18 style='height:13.5pt'
{x:str border=0 cellpadding=0 cellspacing=0 width=738 height=17 style='height:12.75pt' align='center' cellpadding=3 border=1
|  height=18 class=xl2315771 style='height:13.5pt' | virtual Audio::Mixer
|  height=17 width=143 style='font-weight:bold;height:12.75pt;width:107pt' | Feature
*getMixer
width=374 style='font-weight:bold;width:281pt' | Backend
|  class=xl2215771 style='border-left:none' | Audio::Mixer *getMixer
width=221 style='font-weight:bold;width:166pt' | Osystem child
|- height=18 style='height:13.5pt'
|-  height=17 style='height:12.75pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual bool
|  height=17 style='height:12.75pt' | virtual keyboard
getFeatureState
|   | DC(softkbd.h), DS(touchkeyboard.h), wince(PanelKeyboard.h)
|  class=xl2215771 style='border-left:none' | bool getFeatureState
|   |  
|-  height=18 style='height:13.5pt'
|-  height=17 style='height:12.75pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual bool hasFeature
|  height=17 style='height:12.75pt' | keymapper
|  class=xl2215771 style='border-left:none' | bool hasFeature
|   |  
|- height=18 style='height:13.5pt'
|   | gp2x, sdl, wince, symbian, ds, palm
|  height=18 class=xl2315771 style='height:13.5pt' | virtual bool openCD
|-  height=17 style='height:12.75pt'
|  class=xl2215771 style='border-left:none' | bool openCD
|  height=17 style='height:12.75pt' | downscaler
|-  height=18 style='height:13.5pt'
|   | MorphOS(morphos_scaler.h), wince(CEScaler.h)
|  height=18 class=xl2315771 style='height:13.5pt' | virtual bool pollCD
|   | DC, gp2x, palm(calc_scale), sdl
|  class=xl2215771 style='border-left:none' | bool pollCD
|-  height=17 style='height:12.75pt'
|-  height=18 style='height:13.5pt'
|  height=17 style='height:12.75pt' | upscaler
|  height=18 class=xl2815771 style='height:13.5pt' | virtual bool pollEvent
|   | MorphOS(morphos_scaler.h), wince(CEScaler.h)
|  class=xl2215771 style='border-left:none' | bool pollEvent
|   | DC, gp2x, palm(calc_scale), sdl
|-  height=18 style='height:13.5pt'
|-  height=17 style='height:12.75pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual bool
|  height=17 style='height:12.75pt' | predictive input
setGraphicsMode
|   | DS(wordcompletion.h)
|  class=xl2215771 style='border-left:none' | bool setGraphicsMode
|   | DS(addAutoComplete)
|-  height=18 style='height:13.5pt'
|-  height=17 style='height:12.75pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual bool showMouse
|  height=17 style='height:12.75pt' | zoning
|  class=xl2215771 style='border-left:none' | bool showMouse
|   |  
|-  height=18 style='height:13.5pt'
|   | wince, symbian
|  height=18 class=xl2315771 style='height:13.5pt' | virtual
|-  height=17 style='height:12.75pt'
Common::EventManager *getEventManager
|  height=17 style='height:12.75pt' | splash screen
|  class=xl2215771 style='border-left:none' |  
|   | gp32(gfx_splash.h)
|-  height=18 style='height:13.5pt'
|   |  
|  height=18 class=xl2315771 style='height:13.5pt' | virtual
Common::SaveFileManager *getSavefileManager
|  class=xl2215771 style='border-left:none' | Common::SaveFileManager
*getSavefileManager
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual
Common::TimerManager *getTimerManager
|  class=xl2215771 style='border-left:none' | Common::TimerManager
*getTimerManager
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual const
GraphicsMode *getSupportedGraphicsModes
|  class=xl2215771 style='border-left:none' | const GraphicsMode
*getSupportedGraphicsModes
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual Graphics::Surface
*lockScreen
|  class=xl2215771 style='border-left:none' | virtual Graphics::Surface
*lockScreen
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual int
getDefaultGraphicsMode
|  class=xl2215771 style='border-left:none' | int getDefaultGraphicsMode
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual int
getGraphicsMode
|  class=xl2215771 style='border-left:none' | int getGraphicsMode
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual int
getOutputSampleRate
|  class=xl2215771 style='border-left:none' | int getOutputSampleRate
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual int
getScreenChangeID
|  class=xl2215771 style='border-left:none' |  
|-  height=18 style='height:13.5pt'
| height=18 class=xl2315771 style='height:13.5pt' | virtual int
overlayToScreenX
class=xl2215771 style='border-left:none' | int overlayToScreenX
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual int
overlayToScreenY
|  class=xl2215771 style='border-left:none' | int overlayToScreenY
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual int
screenToOverlayX
|  class=xl2215771 style='border-left:none' | int screenToOverlayX
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual int
screenToOverlayY
|  class=xl2215771 style='border-left:none' | int screenToOverlayY
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual int16 getHeight
|  class=xl2215771 style='border-left:none' | int16 getHeight
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual int16
getOverlayHeight
|  class=xl2215771 style='border-left:none' | int16 getOverlayHeight
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual int16
getOverlayWidth
|  class=xl2215771 style='border-left:none' | int16 getOverlayWidth
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual int16 getWidth
|  class=xl2215771 style='border-left:none' | int16 getWidth
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual MutexRef
createMutex
|  class=xl2215771 style='border-left:none' | MutexRef createMutex
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual OverlayColor
ARGBToColor
|  class=xl2215771 style='border-left:none' | OverlayColor ARGBToColor
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual OverlayColor
RGBToColor
|  class=xl2215771 style='border-left:none' | OverlayColor RGBToColor
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual uint32 getMillis
|  class=xl2215771 style='border-left:none' | uint32 getMillis
|- height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void
beginGFXTransaction
|  class=xl2715771 style='border-left:none' |  
|-  height=18 style='height:13.5pt'
| height=18 class=xl2315771 style='height:13.5pt' | virtual void
clearFocusRectangle
class=xl2715771 style='border-left:none' |  
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void clearOverlay
|  class=xl2215771 style='border-left:none' | void clearOverlay
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void clearScreen
|  class=xl2215771 style='border-left:none' | void clearScreen
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void colorToARGB
| class=xl2215771 style='border-left:none' | void colorToARGB
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void colorToRGB
|  class=xl2215771 style='border-left:none' | void colorToRGB
|-  height=18 style='height:13.5pt'
| height=18 class=xl2315771 style='height:13.5pt' | virtual void
copyRectToOverlay
|  class=xl2215771 style='border-left:none' | void copyRectToOverlay
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void
copyRectToScreen
|  class=xl2215771 style='border-left:none' | void copyRectToScreen
|-  height=18 style='height:13.5pt'
| height=18 class=xl2315771 style='height:13.5pt' | virtual void delayMillis
| class=xl2215771 style='border-left:none' | void delayMillis
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void deleteMutex
| class=xl2215771 style='border-left:none' | void deleteMutex
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void
disableCursorPalette
| class=xl2215771 style='border-left:none' | void disableCursorPalette
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void
displayMessageOnOSD
|  class=xl2215771 style='border-left:none' |  
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void
endGFXTransaction
| class=xl2215771 style='border-left:none' |  
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void grabOverlay
| class=xl2215771 style='border-left:none' | void grabOverlay
|-  height=18 style='height:13.5pt'
| height=18 class=xl2315771 style='height:13.5pt' | virtual void grabPalette
|  class=xl2215771 style='border-left:none' | void grabPalette
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void hideOverlay
|  class=xl2215771 style='border-left:none' | void hideOverlay
|-  height=18 style='height:13.5pt'
| height=18 class=xl2315771 style='height:13.5pt' | virtual void initBackend
| class=xl2215771 style='border-left:none' | virtual void initBackend
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void initSize
| class=xl2215771 style='border-left:none' | void initSize
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void lockMutex
|  class=xl2215771 style='border-left:none' | void lockMutex
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void playCD
|  class=xl2215771 style='border-left:none' | void playCD
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void quit
|  class=xl2215771 style='border-left:none' | void quit
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void
setCursorPalette
|  class=xl2215771 style='border-left:none' | void setCursorPalette
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void
setFeatureState
|  class=xl2215771 style='border-left:none' | void setFeatureState
|-  height=18 style='height:13.5pt'
| height=18 class=xl2315771 style='height:13.5pt' | virtual void
setFocusRectangle
|  class=xl2215771 style='border-left:none' |  
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void
setMouseCursor
|  class=xl2215771 style='border-left:none' | void setMouseCursor
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void setPalette
|  class=xl2215771 style='border-left:none' | void setPalette
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void setShakePos
|  class=xl2215771 style='border-left:none' | void setShakePos
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void
setWindowCaption
|  class=xl2215771 style='border-left:none' | void setWindowCaption
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void showOverlay
|  class=xl2215771 style='border-left:none' | void showOverlay
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void stopCD
|  class=xl2215771 style='border-left:none' | void stopCD
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void unlockMutex
|  class=xl2215771 style='border-left:none' | void unlockMutex
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void unlockScreen
|  class=xl2215771 style='border-left:none' | virtual void unlockScreen
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void updateCD
|  class=xl2215771 style='border-left:none' | void updateCD
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void updateScreen
|  class=xl2215771 style='border-left:none' | void updateScreen
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2315771 style='height:13.5pt' | virtual void warpMouse
|  class=xl2215771 style='border-left:none' | void warpMouse
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2615771 style='height:13.5pt' |  
|  class=xl2215771 style='border-left:none' |  
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2615771 style='height:13.5pt' |  
|  class=xl2215771 style='border-left:none' | void mouseToSoftKbd
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2615771 style='height:13.5pt' |  
|  class=xl2215771 style='border-left:none' |  
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2615771 style='height:13.5pt' |  
|  class=xl2415771 style='border-left:none' | void checkSound
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2615771 style='height:13.5pt' |  
|  class=xl2415771 style='border-left:none' | void drawMouse
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2615771 style='height:13.5pt' |  
|  class=xl2415771 style='border-left:none' | void setScaling
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2615771 style='height:13.5pt' |  
|  class=xl2415771 style='border-left:none' | Common::SaveFileManager
*createSavefileManager
|-  height=18 style='height:13.5pt'
|  height=18 class=xl2615771 style='height:13.5pt' |  
|  class=xl2215771 style='border-left:none' | &nbsp;<&#33;[if supportMisalignedColumns]>
|-  height=0 style='display:none'
|  width=444 style='width:333pt' |
|  width=444 style='width:333pt' | <&#33;[endif]>
|}
|}
== 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.

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.