[Scummvm-devel] 0.9.0 plans

Max Horn max at quendi.de
Tue Apr 18 00:56:03 CEST 2006

Am 18.04.2006 um 03:16 schrieb Torbjörn Andersson:

> Eugene Sandulenko wrote:
>> I would recommend to do testing in each engine and split it to  
>> several
>> bugreports, assigning to each engine maintainer. This way it could
>> really get solved, otherwise it will be difficult for a random
>> developer to fins appropriate place in each engine.
> Pfft. That's far too much work for my taste.  :-)
> I've gone through most of the engines myself, and added extra calls to
> updateScreen() (most engines have a delay function of some sort, which
> seemed like a good spot for it).
> Engines I've changed:                   lure, queen, SCUMM, sword1
> Engines which seemed ok already:        cine, gob, kyra, SAGA, sword2
> Engines which may still need attention: simon, sky
> But I'm far too tired to do any more tonight.

Question is, is that the right way to go about it or not... but I  
don't mind a solution being implemented right now, just wondering if  
it's "the best".

E.g. the SDL backend could be modified to automatically redraw the  
mouse again; the point simply is, to do so, it shouldn't just call  
updateScreen, as it did so far.

The problem with updateScreen just indicating that the "dirty parts"  
should be updated is that it shifts all the responsibility for  
maintaining a "dirty rect list" to the backends, which makes it that  
much harder to write good & efficient backends. Of course the  
advantage is that it's easier to write frontends. One could also  
argue for reversing this: Since the frontends have a lot more  
information (at least in theory) about what they are doing, they  
could possibly do a better job at managing these things.

That's why SDL offers SDL_UpdateRect, SDL_UpdateRects and SDL_Flip to  
its clients, but not "dirty list management".

Now, if we would make such a big shift, the backend maintainers could  
rejoice (well... not quite, since they'd also have to modify their  
backends, though it should be relatively trivial), but the engine  
maintainers would groan and complain, and have to do lots of work to  
their engines.

Maybe a better solution to all this would be to insert a layer  
between backends and frontends here (just like we do for Audio  
(mixer), CD playback, savegames, GUI, ... :) which does the mid-level  
task of dirty rect management... AFAIK the SDL backends is by far the  
most sophisticated backend in this regard anyway, though i could be  
mistaken. The whole idea is still rather fuzzy, and maybe not good at  
all. Problem for me is, I am not aware enough of the needs of our  
ports (and how could I be -- the only way for me to find out about  
them is to read the source of all these backends, get corresponding  
devices to test them, and basically retrace every step of the  
porters, and their "workarounds" for problems in the ScummVM APIs :-/).

That's all not something for the next release. But I am really  
wondering whether the way we do things really is the "easiest" or if  
we aren't by chance complicating some things for both porters, by  
forcing them to implement full dirty management (which even the SDL  
backend isn't that great about right now anyway).


More information about the Scummvm-devel mailing list