[Scummvm-devel] SDL backend modularization remarks

vgvgf vgvgvgf at gmail.com
Mon Jun 7 23:38:49 CEST 2010


Hi Max,

> That might be helpful, aye! The less common code backend authors have to re-implement, the easier it gets to write and maintain backends, and to adapt them to future API changes.
> However, for now it is important that this is not forced upon devs, i.e., I'd put this into a "ModularOSystem" or "ModularBackend" class, derived from OSystem; this will make transition to the new modular system easier, and for ports which already work well and are not going to share much code anyway, it means that they are not forced to suddenly modularize everything.
Ok, then I will create a ModularBackend, for not messing with other backends.

> Now something else: On your wiki, you wrote: "There are some problems I still need to fix, like where to place shared code between the subsystems or how is the better way for the managers to interact with each other." Well spotted, this is indeed one of the things that need some thought. Have you already identified specific things that may need sharing?
Yes, some of them are commented in my code, with some FIXME until I
find the best solution. For example:
_km (for keyboard mouse pos), used in both events and graphics
functions. It's largely used in events, so I will put it in the
SdlEventManager when done, but it's modified in graphics in
loadGFXMode. I think that I'll move the code that modifies it in the
graphics manager to a new resetKM() method in events and call it from
the graphics manager.
_modeChanged from graphics is toggled in pollEvent for
EVENT_SCREEN_CHANGED. Now I have it on public on the graphics manager,
but I should change that and use a function instead. Also, the same
goes for _forceFull in graphics.
_mouseCurState from graphics needs to be updated when the cursor pos
changes in events. Now, the events code call setMousePos in graphics
manager. I could leave it as it is, or maybe something better can be
done to update the cursor pos in graphics.

However, I'm focusing now on finishing the code division between the
managers first , and then I'll start looking for those methods and
data that is needed to be shared with the other managers. When
finishing all managers, it should be easier to relocate and create
functions for accessing data or telling the other managers to do
something.

> Finally, some remarks on DefaultGraphicsManager: Its destructor should be made virtual. And I actually think it would be better to have a GraphicsManager() base class, with all those mandator methods made pure virtual, and let SdlGraphicsManager inherit from that. And DefaultGraphicsManager should be renamed to NullGraphicsManager, as that is what it does: Implement an "empty" graphics manager, suitable for a modularized version of our "null" backend. It is *not* a "default graphics manager" in the sense that a real backend would actually want to use it, unlike e.g. the DefaultTimerManager.
Right, I have been treating null and default classes as the same
thing, when I shouldn't. I will then create a BaseGraphicsManager, as
a pure virtual class, and have the actual DefaultGraphicsManager
renamed to NullGraphicsManager.
And, for a real DefaultGraphicsManager I could implement the
fillScreen and displayMessageOnOSD that are now in BaseBackend, and I
could also implement some basic variables, like _width, _height,
_overlayVisible, _videoMode, and some others as well as some functions
that seem to be used in all backends. Or maybe leave it as it is now,
and make each derived manager to implement all on its own. What do you
think?

Regards,
Alejandro




More information about the Scummvm-devel mailing list