Fixing time step

Sure, but online/networked play usually depends on synchronization, so you need varying machines to update their simulation at the same rate in order to keep the simulation in sync. Solving physics simulations is also more stable at fixed time-steps.

It really depends on the requirements of your game.

It is necessary for online play and physics/game simulation. It is unrelated to basic animations, though if animations have more complex features such as the ability to trigger events in the game such as voices, cut-scenes, damage-dealing, or other things then it would be a good idea to use a fixed time-step.

The basic way to think of it is that anything with a foundation in logic should be fixed, while anything that is purely graphical can be variable. Basic animations are generally purely graphics, but more complex ones may tie into simulation logic. You will have to decide for yourself which way to go.


L. Spiro

The reason I ask is because if you are calculating times for animation tracks, you can just get the current time and use that as a reference point for local animations. I've done this and it seems to work pretty much spot on for animation timings, no matter how long your frame time is.

What happens if your game freezes for an entire second? Whether or not the animation is correct, the world will have advanced a whole second and the user will be confused about what happened in that time. For simple problems, maybe one doesn't need a fixed time step, but there should at least be a maximum allowable amount of time to pass in one frame.

Thanks for the replies guys.

What happens if your game freezes for an entire second?[/quote]

I'm not sure if this would matter too much..? If you're mapping animation to actual time, when the frame finally appears, it will use the appropriate animation frame (interpolated between key frames,, etc) based on the local timeline of the animation. No matter when the frame is drawn, you'll sill know the absolute time so if you have two or three complex animation blends, it should still know where in the set to draw.

With regard to network play, I think if each client synchronises their clock at the start, wouldn't this negate the need for fixed time step?

I need to do some more reading on this but I was also wondering what happens with 3rd party physics libraries, how do they match up to your frame timing? Does it have all that built in itself or would you need to pass it delta times?

Thanks for the replies guys.

What happens if your game freezes for an entire second?[/quote]

I'm not sure if this would matter too much..? If you're mapping animation to actual time, when the frame finally appears, it will use the appropriate animation frame (interpolated between key frames,, etc) based on the local timeline of the animation. No matter when the frame is drawn, you'll sill know the absolute time so if you have two or three complex animation blends, it should still know where in the set to draw.

With regard to network play, I think if each client synchronises their clock at the start, wouldn't this negate the need for fixed time step?

I need to do some more reading on this but I was also wondering what happens with 3rd party physics libraries, how do they match up to your frame timing? Does it have all that built in itself or would you need to pass it delta times?

I'm not sure if this would matter too much..? If you're mapping animation to actual time, when the frame finally appears, it will use the appropriate animation frame (interpolated between key frames,, etc) based on the local timeline of the animation. No matter when the frame is drawn, you'll sill know the absolute time so if you have two or three complex animation blends, it should still know where in the set to draw.

That is just the animation of your character. What about the simulation of the game world?
If the game stops for 1 second, then starts again, and if you then pass a 1-second time-stamp to the physics engine, suddenly everything slams into the ground due to a second’s worth of accumulated gravity and suddenly bounces up into the air.
This is called a physics simulation explosion. It is well understood and a common artifact of variable-length time-steps.
As I said before, anything that needs to simulate the physical world or game logic should be on a fixed time-step.

With regard to network play, I think if each client synchronises their clock at the start, wouldn't this negate the need for fixed time step?

Not at all. Firstly, synchronization is on-going, not just a once-at-the-start thing.
Secondly, you aren’t understanding the implications of different time-steps when running a physics simulation.
Two computers are playing a networked game. One is twice as fast as the other so it runs updates twice as fast.
When an object smacks into a wall, the computer with the slower time-step allows the object to interpenetrate the wall deeper than the faster computer would, thus changing the location of contact and possibly the angle of reflection, thus sending the object bouncing in a different direction than the faster would have.

With fixed time-steps the object interpenetrates by the same amount on each client and thus gets bounced off exactly the same for each client, baring differences floating-point modes. These tiny differences accumulate much less severely and are part of the cause for on-going synchronization.


L. Spiro

Thanks again for the replies, I think I'm starting to get to grips with it now.

One thing though - in the GoG article, he puts in his code that if the frame time is greater than 0.25 then clamp it at 0.25 - what happens here if there is a one second delay in the logic? It will only move on by 0.25 won't it?

That is a common decision among single-player games. After a certain limit, the game simply stutters until it later catches up to the real game time.

This is not used for online games, however, and it is at your discretion to use it.


L. Spiro

Thanks L.Spiro

I just read your website about this subject and it was very informative - you write really well.

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.

I wouldn’t accept such a discrepancy myself.

You are likely accumulating small errors over many iterations/frames. This can and will happen if you accumulate time using floating-point values etc.
You will need to show how you accumulate time, including the types of all variables involved.


L. Spiro

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.

As a side note. We using computers can go great lengths how this is inaccurate. But, in generic science, to produce an accurate measurement you need instruments guaranteed to be as accurate and a methodology guaranteed to be compatible with instrument accuracy.
Both your tests are visual and manual as long as I understand. The methodology does not appear adeguate to guarantee this level of accuracy, much less to drive serious decisions.
By generic scientific method.
As a fact, being off by .2s after 10 minutes looks compatible with reaction time.

I'd investigate the issue for further confirmation (nobody really wants to accumulate errors too much) but I wouldn't jump in to fix this.