[SDL] Input latency in OpenGL?

[David Olofson]

On Sunday 20 January 2008, Iori Branford wrote:
> Turns out I was drawing the scene way more times than I needed,
> probably causing excess v-blank waiting. When the draw rate is
> clamped to my target framerate, instead of drawing after every
> input/logic update, the latency is practically gone.

That certainly explains it. :-)


> All I need now is a way to calculate the screen refresh rate so I
> can clamp the draw rate to that instead.

That's not how you'd normally do it - at least not in any normal 
applications. Might work in a simulator, console or arcade machine 
where you can guarantee that you always maintain a steady full frame 
rate, ie constantly rendering one frame per display refresh - but 
even then, you may have to deal with different systems (ie PAL vs 
NTSC in consoles) having different display refresh rates. Normally, 
you'll also have to deal with the frame rate sometimes or constantly 
dropping below the display refresh rate, in predictable or 
unpredictable ways.

The best you can do, that's still generally safe, is to time each 
frame, grab all input and (one way or another) advance your logic to 
match the expected time of the next frame displayed. There are many 
ways of doing this (scaling logic "steps" by delta times, fixed logic 
frame rate, logic in a separate fixed rate thread etc), but the 
general idea is that you make your application somehow dynamically 
scale with the actual rendering frame rate. You need to separate 
logic timing from video frame timing.

For extremely sensitive applications (fast games and simulators), you 
*may* improve input timing accuracy by gathering input in a high 
priority background thread that timestamps events as they come in. 
(It's a tried and tested solution for audio/MIDI applications on 
reasonably well behaved multimedia operating systems.) That said, I'm 
not sure you can actually do this portably with SDL, and in my 
experience, it doesn't work reliably on Windows systems; at least not 
with a single CPU/single core. It's a technically sound design for 
suitable platforms, but you can't assume that your average general 
purpose OS will handle it properly.


//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  --'