• entries
45
44
• views
50698

4100 views

[color=#ff8c00]

# Another way to fix your timestep:

[/color]

the famous article "fix your timestep":

http://gafferongames.com/game-physics/fix-your-timestep/

attempts to address the problem of your simulation not running at the same speed on all PC's:

1. first, variable timestep is used to get the same speed on all pc's - but variable timesteps which are large can make physics blow up, large et's can cause the spiral of death, and variable timesteps are non-deterministic.

2. semi-variable timestep is then used to eliminate physics blowing up due to large et, but sim bound games and large et's can still cause the spiral of death, and semi-variable timesteps are still non-deterministic.

3. a render bound or et capped semi-variable timestep is used to eliminate the spiral of death. but the semi-varible timesteps are still non-deterministic. Note that render bound only prevents spiral of death from long update times, not from long render times, which requires an et cap.

4. it is ASSUMED that the game needs to be deterministic - an assumption which is not necessarily valid for all games.

5. fixed timestep with variable render speed is used to make the sim deterministic, but this leads to temporal aliasing. although not implemented in the example, an et cap can be used to avoid the spiral of death.

6. fixed timestep with variable render speed, and interpolation from previous to current state when rendering is used to eliminate temporal aliasing. although not implemented in the example, an et cap can be used to avoid the spiral of death.

after all of this you get:
1. same sim speed on all pc's
2. no large dt's to blow up physics
3. no sprial of death from large et's
4. deterministic behavior
5. no temporal aliasing
6. renders as fast as possible, possibly even faster than refresh rate if et is small enough.

# [color=#ff8c00]Here's an alternative:[/color]

[color=#0000ff]while !quitgame[/color]
[color=#0000ff]{[/color]
[color=#0000ff]render[/color]
[color=#0000ff]process_input[/color]
[color=#0000ff]update // with a fixed_dt[/color]
[color=#0000ff]while (elapsedtime[color=#0000ff]}[/color]

this is a basic game loop with a framerate limiter.

1. it runs at the same speed on all pc's
2. fixed_dt is always small, so physics won't blow up.
3. always one render and input per update, so no spiral of death.
4. fixed_dt is a constant value, so its deterministic.
5. render is based on the exact current state of the sim, so no temporal aliasing.

the only difference:
fixed timestep will render as fast as possible - perhaps even faster than the refresh rate. framerate limited will only render as fast as you specify via maxfps (where: maxfps=1/min_frametime). by selecting maxfps to be as close to refresh rate as possible, this difference can be minimized. if maxfps = refresh rate, the difference is eliminated entirely. in fact, when min_frametime = et_cap, the two loops behave identically.

additional benefits of framerate limited:
1. no need for a loop to update in dt sized chunks.
2. no need for an accumulator.
3. no need to track both previous and current states.
4. no need to interpolate for rendering.
5. no need for an et cap to avoid the spiral of death.
6. more accurate: render shows the actual current state, not the state as it was dt seconds ago (a side effect of interpolating from previous to current state, instead of predicting from current to next state).
7. by selecting a lower maxfps, the game can have longer et's without any noticeable slowdowns. this means means more milliseconds per frame to draw, process input, and simulate.

# [color=#ff8c00]So, why does fix your timestep go to all that work to accomplish almost the same thing?[/color]

it seems to stem from two assumptions:
1. you want the sim to run at the same speed on all pcs all the time, irregardless of et, as opposed to simply not running too fast when et is not large.
2. the game needs to be deterministic.

because they try to make it run at the same speed all the time by using variable et, instead of simply trying to make it not run too fast, they create, then solve a series of problems, adding code complexity with each new solution:

1. variable timesteps are added to make the sim run at the same speed all the time, but long et's can make the physics blow up, and can lead to the spiral of death. also, variable timesteps are non-deterministic.
2. semi-variable et's are used to keep the physics from blowing up, and an et cap is mentioned as a way to avoid the spiral of death, but this still doesn't make the code deterministic.
3. fixed timestep with variable render speed (and et cap to avoid spiral of death - one would assume) are used to make the code deterministic, but leads to temporal aliasing.
4. finally, interpolation from previous to current state is used when rendering to eliminate temporal aliasing.

# [color=#ff8c00]So, is fix your timestep worth it?[/color]

it depends:

1. fixed timestep will render as often as possible - perhaps even faster than the refresh rate. framerate limited never renders faster than the maxfps you specify, but you can specify the maxfps to be equal to the refresh rate (or even higher - but there's not point in rendering faster than the refresh rate). when et_cap = min_frametime, the two loops behave identically.

2. fixed timestep draws the scene as is was dt seconds before the current state, not as it actually is at the time of render. framerate limited always renders the exact current state.

# [color=#ff8c00]Its your call, does it sound like its worth it to you?[/color]

Your solution will lead to jittering when computation takes ~ desired frame time. This may happen all the time due to scheduling conflicts in the OS. You opt to slow down the whole simulation if you can't keep up. This leads to your game character running at, say, 1/2 real time speed only to switch back to full speed and back - it jitters. E.g. take a frame rate of 10 FPS:

Real Time Game Time
0             0
0.1          0.1
0.2          0.2
0.4          0.3 <- lagging
0.6          0.4 <- lagging
0.7          0.5
0.8          0.6


The 0.2 seconds are lost. Your simulation ran slower during the lagging frames and there's nothing you can do about it. So it doesn't run at same speed on all machines. Advanced game loops might catch up if simulation doesn't take too long.

If you start lagging heavily you have to drop frames, effectively slowing down the simulation. You're doing it implicitely by only simulating a single update step. Advanced game loop drop accumulated (and not yet accounted for) real time. There is no way around it. That's one of the reasons multiplayer lockstep simulations may halt - if one machine can't keep up all others have to wait for it.

The benefit of advanced game loops is that they cope with OS induced jitter that can be easily handled by performing 2 update iterations in a single render frame. The render delay is most of the time either irrelevant (say 60Hz game state updates) or can be masked (by animating wrt render rate instead of game logic rate).

To be frank, I don't see the advantages of your scheme as I understand it, except that my laptop might be killed by your busy wait loop :)

##### Link to comment

I agree with @duckflock; while it does cut down on temporal aliasing, it has three issues that jump out at me:

• It seems as if this drops updates rather than frames, which can lead to a discrepancy in gameplay (people trying to cheat online/trying to engage "slow-motion" by increasing the load on their machine).
• If update or rendering takes too long, all expectations are gone; all of a sudden, rather than the game busy waiting (and not repainting. Black window if you move it around before it repaints?), time no longer matches wall clock time: 1 second in real life no longer counts as a second in game, and the game enters slow-motion as they update slower than realtime.
• Busy loop consumes quite a bit of CPU time.

I would recommend writing an actual program that demonstrates this concept, to better get your point across.

edit: Editor doesn't like bulleted lists?

##### Link to comment

I have to double this, your solution seems to have some drawbacks.

A dogmatic fix-your-timestep approach might push your game into a spiral of death, but you typically only apply this on critical parts of your game. Eg. game logic, animation, most rendering stuff, pathfinding etc. don't really need a fixed time step, a dynamic timestep is sufficient. Particle emission, physics depends on a fixed timestep, skipping one or more timestep will result in appreciable stuttering.

So, instead of putting it into your game loop shift the fixed timestep into sub-components in need of it.

##### Link to comment

>> You opt to slow down the whole simulation if you [the compter] can't keep up.

exactly. i consider it less player-unfriendly than having the simulation continue at real time speed while only render and input slow down. the speed of render and input dictates the "speed" the player can run/play at. if they slow down and the simulation doesn't, from a player point of view, the simulation is running faster than the player interface is, and the game can become momentarily unresponsive to the point of being unplayable. unfortunately, slowdowns often occur in heaviest combat, IE when the player is in a big life or death battle, exactly the WRONG time for the user interface to slow down with respect to the simulation.

the idea is to limit the fps rate to worst case all the time. if heavy combat in your title drops you from 55 or 60 down to 35 fps, you set the limiter to say 40 fps. granted, you do lose 20fps worth of animation smoothness, but your game doesn't become unplayable in heavy action.

obviously, games that don't stress the limits of the hardware much or in a spikey manner don't need to worry about playability at low frame rates. this is probably most useful for some sort of hard core combat sim that really pushes the limits of the hardware. - submarine simulators come to mind as an example.

##### Link to comment

>> (people trying to cheat online/trying to engage "slow-motion" by increasing the load on their machine).

this approach is for high accuracy single player simulations. in a multi-player environment, such a game would require lockstep sync to maintain simulation accuracy.

>> I would recommend writing an actual program that demonstrates this concept, to better get your point across.

looks like i've done a total of 37 games that way over the years:

Caveman 3.0 beta 14, released dec 26th, 2014:

http://rocklandsoftware.net/beta.php

Other titles with framerate limiters (from the Rockland website):

Caveman v2.0 - Caveman VR (2008) - Virtual reality caveman simulator / RPG / FPS. Unreleased.

Combat Racer (first release 2003) - Armored gravcar racing combat simulator with vehicle design and built-in track, race series, and game editors.

Cybertank (first release 2002) - Gravtank combat simulator with vehicle design, squad level operations, and built-in editors.

Caveman (first release 2000, 3 versions) - Caveman simulator / RPG / FPS in the style of The SIMs, with FPS combat, FPS settlement exploration, and FPS cavern exploration.

Gamma Wing (first release 1994, 5 versions) - Space fighter simulator similar to Wing Commander.

Armies of Steel (first release 1993) - Realtime wargame with high resolution graphics, animations, and mouse driven interface.

Combat Zone (first release 1993) - Arcade style realtime wargame with high resolution graphics, animations, and mouse driven interface.

Siege! (first release 1990, 3 versions) - realtime castle construction and siege combat simulator.

Tank (first release 1989, 6 versions) - Arcade tank combat / tank combat simulator. Originally a clone of the arcade classic top down view red vs blue tank, this evolved into a squad level realtime tank combat simulator with vehicle design and helicopters.

Mordorventure III (first release 1989, 6 versions) - Fantasy RPG with dungeon, wilderness, and city adventure. Included realtime individual combat, castle construction and siege combat, and realtime medieval army combat.

SIMTrek / SIMSpace (first release 1988, 8 versions) - Star Trek style forward view realtime capital starship flight and combat simulator with mouse driven interface. The game that started the Star Trek flight sim genre.

##### Link to comment

>> So, instead of putting it into your game loop shift the fixed timestep into sub-components in need of it.

unfortunately, the whole point is that the UI (render and input) should never run slower than the physics simulation (update) to avoid playabilty issues when ET momentarily goes high. this implies that they should be in lockstep when ET is high.

I see no reason why the UI shouldn't run faster than the simulation when possible, for smoother animation and more responsive input. this would lead to a semi-decoupled design.  lockstep when ET is high, variable timestep when ET is low. I'll have to think about how to best do that. i've done a lot of research on variable vs fixed timestep. i think one of the designs i investigated yielded that behavior. which is the best of both worlds.

it seems the typical approach today is to use variable timestep, then simply not tax the hardware too much. but this leads to design constraints based on hardware such as "scene complexity can never exceed 50-55fps minimum". well, what if you want to do a complex simulation where today's hardware just can't do that? do you wait 10 years? or do you change the rules: steady state minimum fps of 35-40, minimum fps in heavy combat of 20 fps.

Right now, caveman 3.0 is running at about 25-35 fps steady state and never drops below 15-20 fps under worst case scenario. its limited to 15fps, so it basically NEVER slows down. that's single threaded on a 1.3 Ghz laptop motherboard with onboard graphics only, and ~100 characters in fps combat. the SIm3 on the same PC gets about 12fps steady state, silent hunter 4 and rome2 total war get 15-20fps. skyrim, about 18fps with graphics set low.

Caveman 1.0 (released in 2000) could do 70 characters in combat with _almost_ no slowdowns.

many years of playing hard core combat sims has shown that 15 fps is about the minimum speed the interface can run at and still be sufficiently responsive to not impact game play. in such games, a momentary drop in interface speed (but NOT sim speed) to say 8, 5, or 3 fps in a life or death combat (the result of variable time step) is really unacceptable.

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account