[Scummvm-devel] Issues with kyrandia engine
Willem Jan Palenstijn
wjp at usecode.org
Tue Jun 8 12:02:05 CEST 2010
On Tue, Jun 08, 2010 at 12:55:25PM +0300, yotam barnoy wrote:
> > So, for those other engines, you happen to be lucky -- but that rate
> > throttling logic is *still* incorrect. Consider this trivial example which,
> > if I understand correctly, will fail to render the text on your backend:
> >
> > drawLogo();
> > g_system->updateScreen();
> > drawText();
> > g_system->updateScreen();
> > g_system->delayMillis(2000); // Let logo & text show for 2 seconds before continuing.
>
> I think what has to be considered is why is there a call to
> updateScreen() in the first place?
If I understand it correctly, in at least the SCI engine this decision is made
by the game scripts and not by the engine itself, so it's not always something we
can change. The example given is artificially simple, but situations like that
do occur.
> As I understand it, after copying
> whatever data the frontend wants to onto the framebuffer, it now needs
> to tell the backend to display this data. Well, if the data is
> displayed for less than 1/60th of a second it's completely useless,
> and in most of our games, even a refresh rate of 1/30th of a second is
> rare. Therefore, if I tell the backend to display something for
> 1/10000th of a second or whatever the example above translates to, I
> can probably expect some weird results, especially given the variety
> of backends we have.
The two updated areas likely were intended not to (fully) overlap in the
example above, so both updates would remain visible for longer.
-Willem Jan
More information about the Scummvm-devel
mailing list