[Scummvm-devel] Issues with kyrandia engine

[yotam barnoy]

> This sounds like your throttling logic is broken. It is only correct if one
> assumes that one either only ever gets rare screen updates (always more than
> 1/30th apart), or always gets very frequent updates (in your case, that
> would mean that screen updates should happen at least 30 times per sec, but
> to be on the safe side and actually always get at least 30FPS, the engine
> would have to make at least 60 updates per sec, cf Nyquist Frequency).
>
> I'm not sampling the updates. I don't need to get at least 30 fps -- I just
want to limit it so I don't get more than 30 FPS. If I update at 60fps I'll
get close to 60fps from SCI, which is way more than I want. Plus I use the
code that's posted on the wiki (which Johannes referenced). Also, there's no
guarantee that 60fps will pick up the update I need.


> A more appropriate approach would be this: Whenever you get a screen update
> request, set a "screen is dirty variable". Then, update the screen from a
> thread resp. triggered by a timer at regular intervals.


Not a bad idea, but it involves 60 extra context switches a second even when
there's nothing to draw, plus protection of all screen operations using a
mutex plus additional complications I'm only starting to think about. I
think that's the reason video processing is usually in the main thread in
games.

If you don't have threads/timers or if those are not available, then a good
> workaround is to hook into various OSystem methods (like pollEvent,
> delayMillis, getMillis, ...) and add code to them which checks if a screen
> update is necessary, and if so, performs one. Various backends (e.g. the NDS
> one) use this approach
>

That feels like a hack to me -- the API is supposed to do one thing and we
really do something else because the proper function isn't being called.
Nevertheless, I think I'll go with this option and just add the processing
to pollEvent.

My opinion is that since the engines are in control of the main loop, they
should call updateScreen regularly, at least so long as there's anything on
the screen. They already telegraph their intentions using the copyRect
calls, so that the backends know when there's a need to update the screen.
This is also the way that all the other engines behave as far as I can tell.
I'm not complaining though -- I understand this behavior was made
specifically for the PSP when the backend wasn't able to handle many
updateScreen calls.

I'll try the slight modification to the engine just to see that this is
indeed the issue, Johannes.

Yotam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20100607/7f94ad27/attachment.html>