[SDL] SDL_PollEvent()

[David Olofson]

On Thursday 09 November 2006 21:52, pixel fairy wrote:
[...]
> > The problem with a delay in the render loop is that it often
> > results 
> > in less smooth animation on properly configured systems (it just
> > interferes with the retrace sync), so you should probably make it
> > optional, or possibly switch it on automatically when needed.
> 
> 
> i like this idea. whats a good way to detect if retrace sync is
> disabled?

Hairy business... Since there is no reliable or portable way of just 
asking the driver, all you can do is analyze the timing and try to 
make some sense of it. Unless you're on a hard real time OS, there 
will likely be loads of timing jitter everywhere. Also, you'd 
probably have to do the testing with very minimal rendering, just in 
case hardware/resolution/scene complexity of the game is too much 
for "full frame rate" as in "one rendered frame for each display 
refersh".

Basically, if you collect timestamps taken right after the 
SDL_GL_SwapBuffers() call, modulo some jitter, you should see a 
granularity corresponding to the display refresh rate. (Of course, 
you'll have to vary the rendering load a bit during the test, to 
avoid confusing your "unsynced" frame rate with the refresh rate 
you're looking for.)

If you're rendering one frame per refresh, then gradually increasing 
the rendering load should have no effect, until rendering a frame 
takes more than one refresh period, at which point the frame rate is 
halved.


Another thing you might want to analyze (simpler, perhaps) is the 
execution times of the SDL_GL_SwapBuffers() call. (That is, compare 
before/after timestamps.) If these are about the same all the time, 
regardless of scene complexity (rendering load), you're not retrace 
sync'ed.

Note that the execution times may be anything from virtually zero for 
a true hardware page flip (the proper way) without retrace sync, 
through several milliseconds for a brute force back-to-front blit 
copy (the way it's usually done in windowed mode on most platforms).


Alternatively, if there's a reliable way of finding out how much CPU 
time your application consumes, you can just check that. (Some 
operating systems may have "funny" ways of measuring CPU load...) If 
it's practically 100% at all times, you're most likely on a display 
setup without retrace sync.


Or, just throw in a manual "Frame Rate Throttling" option. :-) I did 
this in Kobo Deluxe - although that was really intended for saving 
battery on laptops. (Kinda' pointless running the CPU and GPU full on 
to push 300+ fps when the TFT can't handle more than 60 fps or so, at 
best.) It just has the side effect of also being useful when an 
annoyed OS scheduler decides block the game for extended periods of 
time, to allow background processes to run.


//David Olofson - Programmer, Composer, Open Source Advocate

.-------  http://olofson.net - Games, SDL examples  -------.
|        http://zeespace.net - 2.5D rendering engine       |
|       http://audiality.org - Music/audio engine          |
|     http://eel.olofson.net - Real time scripting         |
'--  http://www.reologica.se - Rheology instrumentation  --'