[Scummvm-devel] SDL backend modularization remarks

[vgvgf]

> Here's a simpler solution that might work (but you should test it): Use EventManager::pushEvent() to insert the screen update event. Drawback: This could lead to multiple screen change events, which could have negative effects.
> Alternative solution: Get rid of _modeChanged. Instead, to determine whether a change occurred, use the getScreenChangeID() method, which is public anyway. A mode change, by definition of that function, occurred if the return value of getScreenChangeID() differs from the previous one. So your event class would store the last value, and the code which checks _modeChange would instead compare this old value to the new getScreenChangeID.
>
> Yet another variation: This logic could be made part of the DefaultEventManager class. That way, backends would only have to implement the getScreenChangeID() API, and the event manager would take care of generating the screen change events.
The getScreenChangeID() comparison seems to be the best choice, as
it's already public and won't generate any conflict with other
graphics managers from other ports. And it's also easy to implement.

>> _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.
>
> Hmm... Any reason you think one might want to do something "better" ? What's wrong with the current way?
The problem I did see on adding public methods to managers, when those
methods aren't in the abstract common base (like in this case
setMousePos), is that when a manager is changed for a special one for
example in another port, there could be some conflicts as they work
different for each platform. However, I find that easy to solve (if
that kind of issue could really happen), as it can be added some
#ifdefs to the conflicting code.

> This reminds me: The WinCE backend has a tweaked variant of the _km code, with some small modifications. Are you looking at how to adapt it (and the Symbian backend, any any using SDL parts), too? The way they work may affect various decisions in how your code is going to work...
> Actually, do you even have a setup to compile the WinCE, Symbian, etc. ports?
No, I've only compiled scummvm for Windows, where I work mainly by
now, and compiled it also for ubuntu. But I've been looking at the
ports codes, but I still need to study them better.
In WinCE backend, the _km code is used just as the normal sdl backend,
but in the Simbian one it's used a bit more, but not really more for
worrying about it much.

Regards,
Alejandro