Yep, even if the time steps don't vary that much between two computers, small discrepancies when doing floating point math will accumulate and after some time the two simulations will get out of sync (and the problem only gets worst as time goes on.)

In fact, with varying time steps, the same computer running with the same inputs can (most likely will) produce different results, which can be problematic when hunting bugs etc.

And yes, L. Spiro's has some great resources

Guys, I thought I had this sussed, but after putting some timings around my implementation, I'm now a bit confused. I thought the idea of fixing your timestep was that you fix your physics step to whatever you want, e.g. 1/10th or 1/60th of a second and the render rate is fully variable. If that's the case, I'm not sure how the code can do that.

I'm sure it does work somehow but I can't get my head around it. You've got a while loop which is doing timesteps for your chosen increment and once you've reached the max ticks for the frame, you do a render. How can the amount of renders ever be more than the number of physics updates? I can't see how it can work...

I'm using the gafferongames example - I read that we 'trick' us into thinking we're using more render frames by interpolating at the end between physics updates, but I still can't see how that can look smooth, if you have 60 updates to do in a frame, you do them all and then render so how can you render more times than you do physics updates.

I'm probably missing something really simple... Could someone please explain?

Thanks

You basically decouple rendering from the physics tick. The basic idea is:

Example, you want to do 20 physics ticks per second, render as fast as possible:

20 ticks per second means you want the time between ticks to be 1 sec / 20 ticks/sec = 0.05 seconds or 50 ms

- keep track of when the last time you did a physics update. (Time A)
- the next physics tick should then happen at (Time A + Time between ticks)

So you'd have a while loop that does something like

[source lang="cpp"]
while (play_game)
{
current_time = getthesystemtime();

while (last_physics_tick + time_between_physics_ticks > current_time)
{
do_physics_tick(current_time);
last_physics_tick += time_between_physics_ticks;
}

// Here you want to draw a frame based on the current physics state
// but the frame would only look accurate if past_physics_tick == current_time,
// so what you want to do is interpolate movement of objects here by:
extra_time = current_time - last_physics_tick.
// aka you want to show things as they currently look, which is
// last_physics_tick + extra_time (= current_time)

// So, this call should draw the frame given the current physics state
// and interpolate the position (or whatever) of the objects based on say
// the latest velocity of the last tick.
draw_frame(extra_time);
}
[/source]

Hope that helps!

Thanks for the write up Rethan, so if your physics step is 1/30th of a second%

Not sure what happened there..!

Thanks for the write up Rethan, so if your physics step is one 30th of a second, lets say, and your physics step takes one 30th of a second to complete, you can only do 30 renders per second right? If your physics step is one 30th of a second and the physics step takes one 60th of a second, you can do 60 renders per second - so in essence, the rendering isn't really decoupled from the physics as such. Is that about right?

Ok, so I did some unit testing around this and I get it now!

Thanks

Well, here are some specific examples:

- if you want to do 30 physics ticks per second, your physics tick function should take (much) less than 1/30 seconds to complete, otherwise you'll start to stutter because you are doing physics all the time and you'll fall behind when rendering frames.

- If you want to do 30 physics ticks per second and your physics tick function takes 1/60 seconds, then you can draw as many frames that can fit in the other 1/60 seconds. So if your draw function is slow, you'll stutter, but if it's fast that will help smooth out the fast moving objects that get interpolated via "extra_time".


If during play there is a hickup (some other process hogs the cpu, some single frame took way long to render than usual etc) and you need to catch up on some physics ticks, you'd end up doing a number of catchup physics ticks before rendering again (which will cause things to jump to the user). This is a case you may want to plan for by limiting the number of catchup physics ticks to run, and/or by limiting the wall clock time that the physics is allowed to take to catch up etc.


So worst cases:
- if your physics takes a long time, your game will become sluggish/slow (the FPS becomes choppy, the game looks like it's in slow-mo).
- if your graphics takes a long time, your game will become unresponsive (things happen that the user can't react to properly).

Thanks Rethan. Sorry for flogging this one, I have finally got things working with my animation but I've run a visual test against simple looping animation which runs on a 1 second loop (my keyframes are between 0.0 and 1.0) and after around 10 minutes, it looks like my animation is edging ahead of time by around 0.2 seconds. I know over 10 minutes this isn't much, but is this generally acceptable? Over 50 minutes we're talking a second out - probably not a big deal but worth checking. Have you guys ever done a test like this on your update timings? (I used my iPhone stopwatch and did it visually).

I'm not really sure where to start looking for this 0.2 seconds or whether it's worth it.