Glenn Fiedler :
to take it even further, you can run the main physics loop entirely on a separate thread which actually runs (in real time) at the number of frames per second the physics should run (say 100hz) and the render thread just reads latest physics state and interpolates, completely independent of physics
this way you are never doing two or more physics updates per-update, so processing is more evenly distributed
in addition, if you gather the input for you simulation on the physics thread, you sample the joystick or keyboard at regular 100hz intervals, which leads to better behavior of your physics
consider this, “fix your timestep version 2.0″

Hi Glenn, thank you for such a beautiful article, nicely done!
I implemented a testbed with box2d and i have the renderer running in the main thread, while the physics and input are running on another one: i’m experimenting the better way of doing things and at this point i can say from my tests that a strict producer/consumer model (that is, a frameNeeded semaphore and a frameReady semaphore) make the physics thread fluctuate since it’s need to wait for the render thread to signal a frameNeeded.
However, implementing it with a mutex protecting the “onRender” call (main thread) and the same mutex protecting the “onUpdate” call (in the other thread), adding “usleep” to avoid both threads concurring much for the lock seems to work flawlessly.
The thing i can’t get to work is the render thread to do subframe interpolation: i mean, everything is fine if the update thread do the subframe interpolation/time aliasing lerp, but if it would work in the render thread as you said it may need less cpu time if vsync is on.
Anyway, let me know if i can send you my code for your own tests: i see you are planning a “fix your timestep v2″ so i’m willing to help you out, although i’m running Ubuntu it shouldn’t be a problem to make v2 cross-platform!

One of the problems I was facing with that idea is that the frame-rate, fluctuating, did not play too nicely with the test sprite I was trying to animate (25 frames… I thought about 0.1 ms per frame would be good…)… for a particular reason I wanted to cap the logic update at a particular frame-rate making sure that it would not be updated faster or slower than a certain rate (to make sure that the animation would run at a specified frame-rate). After a bit of thought it occurred to me too that I would need to accumulate time…

-(void) updateLogic {
float dyDroplet = (344.0f/11.0f); //watch out for the .0f, not to make it an integer division

if (frameIndex > 9 && frameIndex (460 – 0.00001f) && frameIndex == 24) {
//equivalent to saying: has the object reached its target && should the animation be restarted?
frameIndex = 0;
dropletXY.y = 52;
drop.center = dropletXY;
drop.image = [self.dropImageArray objectAtIndex:frameIndex];
return;
}
drop.center = dropletXY;
if ((dropletXY.y + 64) > 450) CMLog (@”Droplet.PaB.y = %f”, (dropletXY.y + 64));
if (frameIndex (MAX_CPF * FRAME_TIME)) {
dt = (MAX_CPF * FRAME_TIME);
//MAX_CPF = (MAX_FPS/MIN_FPS); FRAME_TIME = (1.0f / MAX_FPS); dt FRAME_TIME) {
while (dt_drop > (dropAnimRate – aEPS)){
//I do not want the animation of the droplet to run either faster than dropAnimRate or slower than that.
[self updateLogic];
dt_drop -= (dropAnimRate – aEPS);
}
dt -= FRAME_TIME;
}

cycles_left_over = dt;
last_time = current_time;

[gamePool release];
}

-(void) drawScene {
CMLog (@”frameIndex = %d”, frameIndex);
drop.image = [self.dropImageArray objectAtIndex:frameIndex];
}

The timer that calls the runLoop method is set to FRAME_TIME:

#define MAX_FPS (120.0f)
#define MIN_FPS (10.0f)
#define FRAME_TIME (1.0 / MAX_FPS)
#define MAX_CPF (MAX_FPS / MIN_FPS)

#define aEPS (0.0001f)

Thanks to it physical simulation in my game now runs much smoothly than ever before!