<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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).<br>


<br></blockquote><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.</blockquote>

<div><br></div><div>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.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> 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<br>

</blockquote><div><br></div><div>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. </div>

<div><br></div><div>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.</div>

<div><br></div><div>I'll try the slight modification to the engine just to see that this is indeed the issue, Johannes.</div><div><br></div><div>Yotam</div></div></div>