[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).
Cheers,
Max
More information about the Scummvm-devel
mailing list