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
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 --'On Sunday 20 January 2008, Iori Branford wrote: