Game Timing

[Sean Doherty]

I have been playing around with delta Time and it appears that it creates a lot of challenges! I was wondering if people prefer delta time over fixed framerate; if so why or why not? I am primary interested in people writting action and arcade games, it probably does not matter when it comes to puzzle or turn based games.

Thanks

[Savant]

it probably does not matter when it somes to puzzle or turn based gaes.
You'd be surprised. Puzzle games have a lot of effects and flashy bits that need to run at the proper speed.

I prefer delta time but that's just me. I've never done anything too fancy in terms of physics so I don't know if fixed frame rate is better for that sort of thing or not.

[ogracian]

Hello,

After getting some "bugs" which only pressent at low fps, I decide to go for
a fixed timestep and I could not be more happy, now my game (woring title :D ) is really solid and behaves consistently independent of framerate.

I suggest the following document, which explain really well how and why use a fixed timestep:

http://www.gaffer.org/articles/Timestep.html

Hope that helps you, regards
Oscar

[Savant]

behaves consistently independent of framerate.
That should happen regardless of the timing method you use. That's the whole purpose behind a timing method. If you weren't seeing that before, are you sure you were doing it right? :)

[Kestral]

http://www.gaffer.org/articles/Timestep.html
I use fixed point vars for my 2D position, velocity, and accel vectors - 32-bit ints with the lowest 8 bits being the fractional part. My projects feel and play the same using the "dt = newTime - currentTime" method whether I am running at 10 fps or 100 fps. The author of this article might have felt that the errors introduced by this method were significant in his case (physics simulation), but I do guess that this is "good enough" for a high percentage of indie game projects.

Thoughts?

[Sean Doherty]

Oscar,

If memory serves, fixed Time step is a combination of Delta Time and only rendering at certain intervals. It is not really fixed frame rate.

I guess what I have noticed is that there are a fair amount of bugs that appear at low frame rates with delta time.

[Chris Evans]

If you're doing an action/arcade game and you want your game to be playable on a wide range of systems, definitely go with delta time. I learned the hard way...

My first game release (Pow Pow's Great Adventure) is framed-based and I definitely regret it now. Frame-based updates are good for console games or if you're targeting a fixed platform spec. But if you want your game to be playable on a wider range of PC systems, then I definitely recommend using delta time. With frame based updates, if someone is only getting 7-10 fps, but the game is meant to run at 30 fps, the game will play like molasses and pretty much be unplayable. With delta, someone at 7-10 fps may have choppy visuals, but it at least the game will run at proper speed and be mostly playable (albeit slightly less responsive).

So earlier this year, I switched all my in-development games to delta time. Changing a frame-based game to delta time is a lot of work, but if you use delta time right from the start of the project it's pretty painless.

Just remember even though you're using delta time you still need to put caps on your movement increments. So even though your space ship might move 20 pixels per second, put a maximum limit of 30 pixels per update so the space ship doesn't jump across the screen if the user's computer stutters for a couple of seconds.

I also use some physics in my current game and still use delta time. Yeah it's a bit tricky, but worthwhile in the end. For example, the physics engine updates at 30fps (or every 30 milliseconds). If on a slow computer it's been 72 milliseconds since the last update, then I run the physics engine twice and store the remaining 12 milliseconds in a variable. Use that value from the variable to offset when the next update should occur. There's a lot more math I'm leaving out, but that's the basic idea and it works great! :)

So bite the initial learning curve and use delta time. :D

[Chris Evans]

Oscar,

I guess what I have noticed is that there are a fair amount of bugs that appear at low frame rates with delta time.

Like I said, use caps on all your movement increments, so your sprites won't jump across the screen on low frame rates and stutters. Also, always check your collision detection before you actually move your sprites/entities.

[svero]

I use fixed timing in all my games except Space Taxi 2. That was the only one where the thrusting didn't seem quite as smooth as I'd have liked.

[Sean Doherty]

I use fixed timing in all my games except Space Taxi 2. That was the only one where the thrusting didn't seem quite as smooth as I'd have liked.

Did you fix the issue by using delta time or did delta time cause an issue with the trust? I assume it fixed the issue?

[svero]

Space taxi uses fractional time, which is essentially a delta time system.

[ogracian]

Well, as Sean says, using a fixed timestep is not relly a FIXED FRAME RATE, like locking your game to run at a fixed frame rate like 18 FPS,which in my humble opinion is not a good solution for pc games, it could work on consoles but not on pcs due to different system configs.

The method suggested in the "Gaffer" article, shows how to update your game at a fixed time step, so this way all your game behaves exaclty the same way no matter your frame rate, obiously at higher fps, your game will be more smooth.

So for example, using a VARIABLE TIME (delta time), here is how the works:

You move all your game objects using deltaTime (to keep it framerate sync), in the following way:

player.pos += vel * deltaTime;

Using the traditional deltaTime, this approach gives you a variable increment in your players pos because deltaTime change frame by frame so if your game is running at 60 FPS, your deltaTime is 1/60, then at other point in your game, runs at 30 FPS, so the player will move twice the last frame!.

This "jumps" in your delta time could cousetroubles like miss collisions, desync, and so on.

By other hand using the fixed time step you avoid all this behaviour, because you use a fixed timestep in the above example if your game runs at 60 fps and your fixed timeStep is 0.01, the player will move exactly the same increment per update (not by frame, because the method could update your game more than one time per frame), so if your game runs at 4 FPS (0.25), and using a fixed timeStep of 0.01 the game will be update 25 times to keep it frame sync.

Worth mention that I use a slightly differen arpoach than the "Gaffer", to avoid a remainder, here is how I handle it:


const int FIXED_TIMESTEP = 1.0f / 100.0f;

//
// Clamps deltaTime
if (deltaTime > 0.25f)
deltaTime = 0.25f;

//
// Updates game using a fixed time step
float timeStep;
while (deltaTime > 0.0f)
{
//
// Update time step
timeStep = deltaTime;
if (timeStep > FIXED_TIMESTEP)
timeStep = FIXED_TIMESTEP;

//
// Updates current state
m_pGameStatesMgr->Update(timeStep);

//
// Dec deltaTime (to match fixed time step)
deltaTime -= timeStep;
}

//
// Draw Game
m_pGameStatesMgr->Draw();

[Chris Evans]

So for example, using a VARIABLE TIME (delta time), here is how the works:

You move all your game objects using deltaTime (to keep it framerate sync), in the following way:

player.pos += vel * deltaTime;




This is what I use as well.

[luggage]

Every retail game I've worked on has used delta time for the main game and maybe a fixed rate for the physics where applicable. It takes a little getting used to but it's straightforward really. And it lets you introduce things like a slow as you like bullet time while still being completely smooth.

My biggest issue with a fixed rate is where the bottleneck lies. If it lies in the rendering then it's a great solution but if it lies with the update you can be in trouble. (As far as I'm aware). Basically, if you've timed everything so your update runs at 120 times per second but the CPU can't handle that, then where do you go?

And just to be fair, a problem with the delta version lies in over compensating. Imagine the following codeball.dy = 9.8f * delta;
ball.y -= ball.dy;

if (ball.y < 0.0f )
{
ball.dy = 0.0f;
}You can't guarantee how far the ball would go less than zero. ball.y might end up as -0.1f or -0.9f or -10000.0f depending on what your frame rate is like.

You end up ensuring the ball is where you want it to be.if (ball.y < 0.0f)
{
ball.dy = 0.0f;
ball.y = 0.0f;
}I hope that makes sense. It's 3.15am and late so blame that if it's wrong!

[princec]

I use fixed time, mainly because it's loads easier, and it looks much better in 2D games. The trick is to pick a fairly poor spec that runs it at full framerate.

Cas :)

[Mike Wiering]

There was a discussion about this earlier: Researching Frames Per Second speeds... (http://forums.indiegamer.com/showthread.php?t=3576)

[gosub]

I use fixed time for movement and hit detection, so all games run exactly the same on all systems regardless of the frame rate. Then I interpolate to the nearest millisecond for rendering so everything runs smoothly regardless of all the weird frame rates you can encounter.

There's a bunch of problems with variable delta timing, such as having an object jump over another object without detecting a collision (hiccup) or having the game run differently depending on the frame rate. The problem with purely a purely fixed delta is that a 100th of a second (or any reasonable fixed delta you choose) won't render smoothly at 60FPS.

So my vote is to use both.

-Jeremy

[Sean Doherty]

Hi Gosub,

I don't follow? You say your using fixed time but everything is running at the same framerate? Can you expand?

Return

[luggage]

gosub: if you use delta timing and it behaves differently at different framerates then you have implemented it wrongly. Seriously - there wouldn't be a 'which one's best' question if one method worked and the other didn't would there?

At the end of the day it's a matter of preference.

[dima]

I don't follow? You say your using fixed time but everything is running at the same framerate? Can you expand?
The point of fixed step is so everything runs the same. If you want your logic running at 1000 FPS, it will, and it will do so on every PC no matter the framerate. You still render every frame, but update code at different frequency, so you get fixed step updates with frame rate independence.

I personally find that fixed step timing is the BEST way to go. Benefits are mostly in stability in timing and reproducing behaviours. You still use delta-time with fixed step timing, except it never changes. Code runs at the same speed on every machine and you can have much higher precision for phisics and such. Definitely the way to go. If you use low frequency updates, might be worth looking into interpolation for silky smooth animations. I made small test which ran at 10 fps and interpolated the animations, ran as smooth and silky as a 1000 fps game.

[luggage]

If you want your logic running at 1000 FPS, it will, and it will do so on every PC no matter the framerate.Is this true though? What if the CPU isn't quick enough to do your update at 1000 FPS? Won't your game start to chug?

[Mike Boeh]

Is this true though? What if the CPU isn't quick enough to do your update at 1000 FPS? Won't your game start to chug?
Maybe not... I have several games that run at 1000 fps internally: Cosmo Bots, Water Bugs, Bugatron, and Z-Ball. The reason they can run at such a high internal logic rate is because the actual game logic is trivial. If the rendering slows it down to 20 fps, who cares? It just runs the logic loop 20 times. Of course, it won't work for every game, but it does for most of mine.

[Sean Doherty]

The point of fixed step is so everything runs the same. If you want your logic running at 1000 FPS, it will, and it will do so on every PC no matter the framerate. You still render every frame, but update code at different frequency, so you get fixed step updates with frame rate independence.

I personally find that fixed step timing is the BEST way to go. Benefits are mostly in stability in timing and reproducing behaviours. You still use delta-time with fixed step timing, except it never changes. Code runs at the same speed on every machine and you can have much higher precision for phisics and such. Definitely the way to go. If you use low frequency updates, might be worth looking into interpolation for silky smooth animations. I made small test which ran at 10 fps and interpolated the animations, ran as smooth and silky as a 1000 fps game.

I thought fixed step used delta time as well as frame limiting as part of the rendering?

[dima]

I thought fixed step used delta time as well as frame limiting as part of the rendering?Frame limiting has nothing to do with fixed step logic. By frame I mean rendering of course. The only reason I see to limit rendering woud be vsync to reduce tearing and such. Other than that, higher framerate = smoother looking game.

[Sean Doherty]

OK, so I am taking a closer look a time stepping and I have a couple of questions from the link provided in this thread:

The call integrate(currentState, t, dt)

1) What is currentState?
2) Why is t being passed?
3) why is dt being passed?
4) I assume integrate is essentially update?

In the function State state = currentState*alpha + previousState*(1.0f-alpha);

1) How is state used? I understand it is a number between 0 and 1, but how is it used in the rendering process?

Thanks

[dima]

What you're looking at is 'tweening' (interpolating between two states like position, rotation, color), you only need to touch this if you're running your logic at a low frequency (like 10-30 times/s), however, if you run your code faster (100-240-1000 times/s) you don't need to worry about interpolating states, because the delta time is very small and animations will be smooth be default. When your logic runs slow (say 30 fps) but in reality the machine is rendering at 300 fps, you're basically rendering 10 frames of the same thing without change, because code has to wait to be executed in proper steps but the rendering is happening as fast as possible, you end up rendering more than once for the same frame. This is where tweening comes very handy; instead of rendering the same thing over and over, you smoothly interpolate between the last two logic steps and render everything accordingly. This way when the Logic is still waiting to be updated, objects are already moving. If your logic is updating fast, it will usually update faster than machine can render, then you get multiple updates per single render, this way there is no need for tweening.

[ogracian]

well in that document the method presented is mainly for physics, so the integrate method handle the physics integration (euler or other similar method), currentState refers to your objects current state like its current pos, its current vel and so on.

As you say, Integrate is mainly a update where all your objects move based in its physics properties.

For a more general solution I suggest the following method (the one I currently use), so is a much simplier way as it do not need to handle a remainder.


const int FIXED_TIMESTEP = 1.0f / 100.0f;

//
// Clamps deltaTime
if (deltaTime > 0.25f)
deltaTime = 0.25f;

//
// Updates game using a fixed time step
float timeStep;
while (deltaTime > 0.0f)
{
//
// Update time step
timeStep = deltaTime;
if (timeStep > FIXED_TIMESTEP)
timeStep = FIXED_TIMESTEP;

//
// Updates current state
m_pGameStatesMgr->Update(timeStep);

//
// Dec deltaTime (to match fixed time step)
deltaTime -= timeStep;
}

//
// Draw Game
m_pGameStatesMgr->Draw();


so in your update method, you move your objects as follows

void Update(float timeStep)
{
player.pos += vel * timeStep;
}


This way all your objects are updated using your fixed time step.

Regards,
Oscar

[Sean Doherty]

ogracian,

I have looked at time stepping article more closley and I think your code is not time stepping? For time stepping you should be passing FIXED_TIMESTEP to the update and your update could be sorrounded by a while statement.

Regards

[gosub]

gosub: if you use delta timing and it behaves differently at different framerates then you have implemented it wrongly.
Not true, especially for chaotic systems. Not true for hit detection. If you want consistent deterministic results, don't use it. (That's just my opinion from experience)
I thought fixed step used delta time as well as frame limiting as part of the rendering?
Fixed step uses a constant delta time per "physics frame." The physics engine is run as many times as necessary to match the frame render time as closely as possible.
I don't follow? You say your using fixed time but everything is running at the same framerate? Can you expand?
For games where the CPU is not overly taxed, Mike (Retro64) probably has the best solution. Use fixed delta timing with a super small delta.

Another thing you can do is select a larger delta, say 0.02 seconds, and then interpolate between two "physics frames" to calculate exactly where the object is when it's time to render the frame. That's more complicated, so I would suggest you follow in Retro64's footsteps.

The main point (for me) is that I want my game to run the same on all systems regardless of the frame rate. Changing your delta randomly will not allow that to happen. I also want them to render smoothly. Using fixed time steps of 100ths of second (or a 60th of a second if the frame rate is 75th of a second) won't allow that to happen.

-Jeremy

[ogracian]

it is fixed time step : ), just look it a little closer, just a little diferent method to avoid the remaining using the article's method.

The important part of the code is the if statement

//
// Update time step
timeStep = deltaTime;
if (timeStep > FIXED_TIMESTEP)
timeStep = FIXED_TIMESTEP;


For example my FIXED_TIMESTEP = 0.01f (100 FPS), and your game is running at 60 FPS (0.0167f) so lets see how it behave in the code


deltaTime = 0.0167f; // (60FP)
while (deltaTime > 0.0f)
is true so enter the while loop.

Now here comes the tricky part

timeStep = deltaTime; // (in this example deltaTime is 0.0167f or 60FPS)
if (timeStep > FIXED_TIMESTEP)
timeStep = FIXED_TIMESTEP;


Here, as timeStep is bigger than my FIXED time step, timeStep use the fixed one (0.01f)

so the update method is called with the fixed time step
m_pGameStatesMgr->Update(timeStep);

for last I decrement the timeStep from deltaTime as follows

deltaTime -= timeStep;


so deltaTime now is 0.0067 and loops again.

Now in the if statement part, now timeStep is 0.0067 (0.0167 - 0.01) which IS LOWER than FIXED_TIMESTEP, so we update using 0.0067 and finish, the advantage of this method is that the loop dose not produce any REMAINDER which could cause some kind of desync and only could be avoided using interpolation (like the article suggest).

I suggest you try this method in the debugger, so you could see how it works much more clear than I could explain it.

Regards,
Oscar

[princec]

3 things I have to contribute to the discussion further:

1. The very fact that no-one seems to just grok it is a hint that perhaps just possibly that it might be far more complicated than it's actually worth

2. It falls over anyway on a slower machine if your logic can't execute fast enough (but I admit that it's bloody unlikely)

3. Running your logic flat out on my laptop causes it to overheat in about 2 minutes and flattens the battery fast when it's off the mains. There's still a good case for being a bit more efficient eh?

Cas :)

[luggage]

gosub: can you explain further. I know of lots of retail games that use delta timing and you're saying it basically doesn't work.

As I said, both systems can fall down.

Fixed: if your update loop can't update fast enough.

Delta: if your framerate is really poor for a sustained period of time.

[dima]

Fixed: if your update loop can't update fast enough.You can update your logic at 30 fps and interpolate the rest, this actually makes less processing for the chip. This method isn't as precise as the higher frequency one, but it taxes your CPU much less. On the other hand, try running logic at 240 times/s, reason I say 240 is that it's at least twice as fast as the fastest refresh rate that i know of, just in case someone has vsync on with 120Hz. This way, even on the fastest machine people will get at least two updates per one render, assuring no need for tweening and making your game very smooth. Just fyi, the PopCap guys use 100Hz logic updates.

The most important reason to use fixed steps (at least for me) is reproducing behaviours. Making game replays becomes a breeze, and they replay exactly the same on any PC, all due to the game going through the same exact states every time it is played back. So when u save the replays, you just save critical user input; key_left_down @ step# 9345, key_left_up @ step# 9477, instead of saving the time when the key was pressed or unpressed, you save the step #, which is going to be exact all the time. All of this is much much more difficult using straight up delta timing and updating and rendering as fast as possible.

[gosub]

gosub: can you explain further. I know of lots of retail games that use delta timing and you're saying it basically doesn't work.
It works reasonably well if you cap your maximum delta, however it won't run exactly the same on all systems if you're doing your hit detection at some random time based on a frame rate. Bigger delta steps (longer times between hit detection) make it more likely that a hit will become a near miss.

You want to show a re-play? Don't use a variable delta.

Ok, I'm biased because I just don't like random variations in my software. I want them to run the same way every time regardless of what the video card is doing.

-Jeremy

[luggage]

I'm still not convinced.

Say you run your logic at 120Hz. What happens if the CPU isn't quick enough? A capped delta system will just get slower but won't break.

The problem you mention regarding missed collisions is a common one. It's called "Bullet Through Paper". This can still happen with a fixed rate. You either have to increase the rate at which you run the logic (which increases the chance of the CPU being too slow) or use a line intersection to determine when and where the collision took place. Using the line intersection fixes the problem for a delta system too.

Unreal Engine 3 uses a delta system - I mean, if the delta system didn't work then I'm sure they'd used a fixed update.

[Nikster]

Luggage hits the nail on the head with "bullet through paper" scenario, some people have the perception of working in fixed frames and carrying that over to
a delta system, most people will do a move object and test if it's hitting anything without actually performing a line intersection and abvisouly hit problems when objects can move either side of the paper, so they either make the paper thicker or the bullet move slower ;) it's also good to get into the whole delta/prediction thing if you ever plan on doing a realtime network game as you're not going to have much luck trying to keep a game synced ;)

[dima]

I'm still not convinced.

Say you run your logic at 120Hz. What happens if the CPU isn't quick enough? A capped delta system will just get slower but won't break.
...
Unreal Engine 3 uses a delta system - I mean, if the delta system didn't work then I'm sure they'd used a fixed update.First of all, at 120Hz, there is almost no chance that cpu wont handle that. Pretty much all bottlenecks come from rendering and only in very rare cases will your logic loop be extremely taxing to the point of not being able to run fast enough. If a PC couldn't handle logic at such high rates, all games would crawl after the rendering accurs. However, some games DO tax heavy with the logic, and for those rare games it makes sence to run logic at low frequencies and use interpolation to smooth things out. In either case, fixed time steps are more useful since they still give you more precise control of your timing and reproducibility. Say you wanted to have multiple logic loops; one for network, one for physics and one for everything else. You could run all these at different rates, like network at 15 fps, physics at 60, and everything else like input at 100. Try doing this without fixed steps. Try making replays work properly on all systems. People have done it, but why not just use a method that is stable and easy to implement. I would say that majority of all games use fixed time steps, Quake does it for sure, don't know why Unreal wouldn't, I'm pretty sure they run their network at a fixed frequency though. In the end, it's up to the developer what to choose.

[Sean Doherty]

Ok,

Originally, I used delta time for my game and here is what I found:

-> Hard to implement correctly for certain things (angles between AI and player often flickered back and forth)
-> Lots of jumping (small and large) as a result of variables step size
-> Poor collision detection
-> Modifications to every module that is being displayed.

I have since switched my code to time steping without delta time (fixed time steps).

-> Extremely easy to implement.
-> Step size pretty much the same on all machines.
-> Game runs more smootly and their was no special code needed for AI to target Players (flickering gone).
-> Code limited to one module.
-> Slower than delta time because there are multiple sometimes multiple updates per render (not with delta time)

Just what I found...

[Jim Buck]

Unless Quake is radically different from Quake2, which definitely doesn't do fixed time steps (though it caps it to a maximum), Quake most certainly doesn't fix the time step.

4d collision detection is what people are getting at.

[luggage]

I'm sure for a simple casual game you would hope 120 hz is low enough to run your logic but this isn't always the case. Trust me, I've implemented Havoc on the PS2, Xbox, Gamecube and PC. The physics took longer to handle than the rendering in every case.

I know you must support the fixed method but what I'm trying to say is - it isn't perfect. There's pros and cons of both methods and you have to decide which one is good for you. eg.

* is your ai complicated?
* how much physics will you be doing?
* will your update be generally slow?
* do you want to use bullet time effects?
* will you be playing back input?

As for this replay thing which seems to be quite important to some of you. In the past when I've worked with a delta system and wanted a replay we just stored off each objects orientation and position. This gave us several advantages...

* it's easy
* it's quick
* playback is simple and lightweight - we could add video effects to it as we had the spare processing time.
* you can skip to any point inside the replay as quick as you like. Try skipping to the end of a 40 minute sequence using a key input method - important for VHS style controls.
* you can slow playback right down to an absolute crawl and it still look smooth.

And, unless you're talking casual only, I disagree - I don't know a single retail developer who currently works with something other than a delta system for their main game. It's just more elegant so long as you can handle the simple math.

Just to make it clear - I'm not saying one way is better than the other. It's just that when people say delta system doesn't work they are incorrect.

[dima]

I use time steps and delta variable. Everything gets scaled by delta sa usual and I can speed or slow things down. Then it's easy to pick the right step frequency for my logic and input, which in my case actually run at different speeds. Logic is confined to 30 fps and input at 120 with a cue to store input. This way input seems much more responsive but logic runs very slowly. I imagine when I start doing network stuff, that will get it's own frequency as well. For now though, I get perfect smooth gameplay (with interpolation) and extremely easy replays, which are tiny compared to saving object data, the only thing you can't really do easily is replay backwards. Speeding up, jumping forward, and jumping backwards is easy as pie. Not great for VHS type playback though, have to reset level an just run continuous logic loop until it gets to the right point, then run the logic normal again.

[gosub]

I'm still not convinced.
I'm not trying to convince you of anything. I was stating my preference from experience. I don't think I have anything else to contribute. You should use whatever method you feel more comfortable with. Have fun :)

-Jeremy