I've read the gaffer on games article and I'm trying to get my head around it. Do you need that for animation timing? Or just movement?
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.
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 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 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.
Author
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?
Author
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
Author
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?
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
This is not used for online games, however, and it is at your discretion to use it.
L. Spiro
Author
Thanks L.Spiro
I just read your website about this subject and it was very informative - you write really well.
I just read your website about this subject and it was very informative - you write really well.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
