[Scummvm-devel] Issues with kyrandia engine

yotam barnoy yotambarnoy at gmail.com
Tue Jun 8 11:55:25 CEST 2010


> 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? 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.

> We are on the same line here: I think it's doable (at least from a theoretical point of view, as I am not familiar with the peculiarities of the PSP), but certainly is far more painful then adding a simple call to updateScreen() to your delayMillis and pollEvent methods (and maybe more).

Yes. Actually I started thinking more about it, and it may be more of
a good idea than I originally thought: the dirty bits on each surface
don't need to be in the mutex since only one thread can update per
state (drawing thread updates off, main thread updates on) and it
doesn't matter if we miss a dirty bit - we'll get it in the next
frame. This means we don't need to take the mutex 30x a second just
for the video thread.

And we can use just one mutex: it'll be taken by the main thread when
the first framebuffer copy is called, and released only after
updateScreen(). The drawing thread will wait on the mutex until it's
available ie until updateScreen() was called, then sleep for 1/30th of
a second minus processing and blocking time.

I don't know if I'll commit it to the tree, but I'll probably create
and test this version for speed.

>
> No, but then most backends do not use rate throttling. The SDL backend for example simply always performs a screen update when updateScreen is called *and* the screen content has changed. Hence it does not have any problems at all.

High-end platforms can afford to do all screen updates including those
requested by SCI. Really I think only SCI causes problems for the PSP
-- it's the only reason I kept the throttling once I added dirty-bit
checks.

Yotam




More information about the Scummvm-devel mailing list