I just changed my fixed timestep from 1/60th to 1/120th of a second and noticed a general increase in the responsiveness of my simulation. My timing is set up just like this article: http://gafferongames.com/game-physics/fix-your-timestep/. Does anyone know if this is likely to carry over on different computers. Logically I would assume that it is more likely that it will take longer than 1/120th of second to compute 1/120th of simulation time than it would be to compute 1/60th in under 1/60th of a second. Then why am I observing a more responsive simulation virtually free of stutter? What do most people use as their timestep?

btw im using bullet as my physics API.

you know you program too much when you start ending sentences with semicolons;

Both of those time-steps are unnecessary in most common cases. 1/60th is usually the highest anyone would go, and 1/30th is the most common. Not every machine can maintain a 60-FPS framerate (much less 120) and in such cases they will simply stutter down to a halt and die, never being able to catch the simulation up to the actual game time.

Define “stutter” and “responsiveness”.
I thought at first you were talking just about input but then you mentioned Bullet, so now I am wondering if you are crossing terms etc.

But let’s assume you are not, and “responsiveness” means “smooth low-delay response to input” and “stutter” means “jerky visuals”.

Smooth input responsiveness can happen at any reasonable time-step interval. If you get less-smooth motions it means there is a problem with how you poll input. Fix that instead of covering it up with a faster update.

Stutter has many explanations, none of which are related to how fast or slow the time-step is. I get perfectly smooth motions on all objects with time-steps as low as 1/5th.
If objects are jerky you will need to explain the nature of the jerkiness. There could be a million causes:
#1: All objects seem jerky all the time when in motion?
-> You aren’t interpolating the objects between updates.
#2: Following an object with the camera is jerky?
-> You are updating your camera’s look-at target only on logical updates, or on every frame but using the wrong target position (you have to look at the interpolated position, which is also updated every frame).

These are the most common, and each indicates its own problem unrelated to fixed time-step intervals. Even at 1/5th you should be seeing everything running smoothly, so changing it to 1/60th or 1/120th is just hiding the problem.

And your “stuff” is more than a very basic 3D game or medium-sized 2D game with no physics?These update rates are absolutely completely unacceptable. See below for why.

Run whatever physics time step you need in order to satisfy the stiffness of your physics subsystem and the requested collision fidelity.

Again, hiding the problem does not fix the problem.

The major question this brings to mind is why you seem to think you need to update logic 1,000 times per second when everyone else is fine with 30 or so.Starsiege: Tribes is fluid and solid at 32 updates per second.Monday Night Combat runs at either 30 or 33.3 (I forgot the specifics). So does Unreal Tournament 2003 and Gears of War.Games using my old engine update at 33.3 times per second. Simulation Golf, Gigander X, Bakugan, etc.All the games made by my company update at 30 times per second (60 in rare cases). Star Ocean 3, Star Ocean 4, Final Fantasy XIII-2, Final Fantasy XIII, War Corps, Valkyrie Profile, Resonance of Fate, etc.

Half of the games I listed use Bullet for physics, so there is absolutely no excuse for the original poster to be cranking his or her logical updates that high. It’s proved thoroughly that Bullet can run just fine and solid on 30 updates per second.

Here is the thing. Starsiege: Tribes is the fastest-paced game listed. It is easy to get speeds up to 2,000 meters-per-second (or easily 1,000,000 meters-per-second if you are the admin typing commands into the console), yet my tiny guy no matter how fast never passes through solids.If my guy went too fast and passed through solids, perhaps your solution would be to increase the logical updates so that he can’t move enough between updates to pass through the object, but you really haven’t solved the problem. The problem is in the physics engine, and the solution is continuous or swept collision detection.With the proper fix in place, not only can you stick with the lower and less CPU-consuming update rate, but you have actually truly solved the problem.

Please do not suggest that such an update rate has no drawbacks just because the things you have done with it weren’t enough to expose those drawbacks. You aren’t making “real” games such as Battlefield 3.If you want to expose those drawbacks even on your small projects, set the update rate to 3,000,000 times per second. Proof that there is such a thing as an update rate that is too high.

Again and again I have to repeat: Increasing your update rate to avoid artifacts is nothing but hiding the problem. There is no problem that can’t be solved by any other means, and a higher update rate than what is absolutely needed is always a bad thing.Virtually every game on the market stays within the 30-48 range, and they all have no problem. If you have a problem with that range, you are doing it wrong, and you have some other part of your engine to fix.

Virtually every game on the market stays within the 30-48 range, and they all have no problem. If you have a problem with that range, you are doing it wrong, and you have some other part of your engine to fix.

maybe virtually every FPS or any game with slow moving actors.

Physics integration rate, again, is a function of system stiffness (ie. if you have spring/damper systems like the one needed for race cars, you need to solve them at high rate to avoid explosions) but this is only part of the problem.. you need to take into consideration the speed the game objects move: if you have a race car cornering at 150kmh and you are integrating at 30Hz as you suggest, you'll have your tyres traveling 1.38 meters between each iteration! Missing every bump and information available in those 1.38 meters by simply "flying" over. That's simply unacceptable for a huge number of game styles... such as racing and flying sims.

Since the OP doesn't give any details about his game, and he calls it "simulation".. your claim that 48Hz should be enough for everybody is simply not true... maybe it's enough for the kind of games that you are used to work on.. but that's where your claim starts and end.

EDIT: One more note about input responsiveness. Again, for game such as driving simulators, running at >100Hz is essential for control and feel of the car... driving controller input at 30Hz or at 100Hz is like NIGHT and DAY from the driver feeling point of view.

EDIT 2: You refer to my software as "small game", so it doesn't count. Would Forza Motorsport be considered a "big game" by Mr. Spiro? Well,guess what? It clocks at 360Hz for the physics. Link:

maybe virtually every FPS or any game with slow moving actors.…Since the OP doesn't give any details about his game, and he calls it "simulation".. your claim that 48Hz should be enough for everybody is simply not true... maybe it's enough for the kind of games that you are used to work on.. but that's where your claim starts and end.

*cough* I think you missed something *cough*

Here is the thing. Starsiege: Tribes is the fastest-paced game listed. It is easy to get speeds up to 2,000 meters-per-second (or easily 1,000,000 meters-per-second if you are the admin typing commands into the console), yet my tiny guy no matter how fast never passes through solids.If my guy went too fast and passed through solids, perhaps your solution would be to increase the logical updates so that he can’t move enough between updates to pass through the object, but you really haven’t solved the problem. The problem is in the physics engine, and the solution is continuous or swept collision detection.

*cough*Slow-moving actors? Actors in Starsiege: Tribes commonly move faster than any actors in any other game of which I can think off the top of my head, including any racing games, including F-Zero and similar. It’s easy to go 700 kilometers-per-hour in Starsiege: Tribes, nearly double the speed of the average F-Zero racers.

Again, simulation was running 32 times per second.

your claim that 48Hz should be enough for everybody is simply not true

No, just truer than saying that upping the update resolution without actually identifying the problem is the correct solution.The math is something like this:In being super generous, we can estimate that 5% of games, often exclusively simulation-based such as racers or flight simulations, require going over 60, and they have a good well understood reason for doing so (note again that only a small number of this class of games actually does—Mario Kart 7 is still either 30 or 60 at all times, never higher).So if your argument is that we don’t know what his needs are, why would you suggest he go the path least likely to be suitable for him statistically speaking?Even if my estimates are wrong (and being estimates, they surely are, but probably not too much), it is in any case far more likely that his problem lies elsewhere.It’s your advice that actually applies to rare special-case instances, and if you are going to give him said advice you should make sure it is actually relevant to his situation. Make sure that actually is the correct solution before you spout off about how bad others’ advice is.

huh? He is asking if it is normal to see a more responsive game running at twice the physical rate and the answer can only be YES.

Your answer was "those rates are unacceptable".

You have been already pointed at 2 MAJOR AAA titles (arguably, the 2 killer application in the respective console business) that contradict your "it's unacceptable" claim.. there isn't much to add to the debate neh?

You have been already pointed at 2 MAJOR AAA titles (arguably, the 2 killer application in the respective console business) that contradict your "it's unacceptable" claim.. there isn't much to add to the debate neh?

Not until you point out why you would tell someone to just increase his update rate without actually knowing what the underlying cause is.I also pointed out many major titles in which an update rate of only 32 times per second provided non-stuttering and stable physics, and many games with nice smooth responsive input at similar rates.

The difference is, I am trying to demonstrate that he shouldn’t be having stutter or non-responsive inputs at lower update frequencies and trying to impress upon him that he should investigate the real cause to this, whereas you are simply trying to win an argument over the Internet.

If you were more concerned with actually trying to help than with trying to win some debate, you would see that there is no way to deny that an overwhelming number of games run responsively and jitter-free at update rates near 30, and that this is an obvious sign that there must be something else wrong with his pipeline.

I’d rather be helpful to the original topic poster than to win some argument online. People keep posting about examples of games that use update rates I said were unacceptable, but they are missing the point.The point was that increasing the update rate prematurely is likely to do nothing more than hide an underlying problem, since so many games can run fine at ~30 ticks per second, no jitter, smooth response to input. Since this much is obvious, and he never said anything about racing games.Which do you think is more likely? He is advanced enough to be making a high-end racing game but doesn’t know common update rates, or that he is an average guy learning game programming with an average-case project and has an average problem with his update rates?

Seriously, enough posts about racing games. I am not here to argue semantics; I am here to help this guy.

L. Spiro

[EDIT]Wow, 3 negative votes; that’s what I get for trying to help instead of trying to win an argument.I modified my first post to satisfy pedantic readers.[/EDIT]

point out why you would tell someone to just increase his update rate without actually knowing what the underlying cause is.

Calm down.No one here has told anyone to arbitrarily increase their simulation rates. Kunos is reacting to your hyperbole.Surely saying that 48Hz is enough for everyone, without knowing what the underlying issue is, is just as offensive as retorting that statement with uncommon examples where 100Hz is justified? Aisde from racing games, street fighter fans would notice if their input was delayed due to a 48Hz sim instead of a refresh-rate sim. We can't make absolute statements in either direction without information.Now, help nicely, and hopefully ic0de can tell us more about his simulation soon so we can find out why 120Hz 'feels' better than 60Hz to him.

Logically I would assume that it is more likely that it will take longer than 1/120th of second to compute 1/120th of simulation time than it would be to compute 1/60th in under 1/60th of a second. Then why am I observing a more responsive simulation virtually free of stutter? What do most people use as their timestep?

It's not really clear from your description what kind of stutter there was before. How many frames per second are you rendering? If your physics update rate is less than your rendering rate there will be some stutter unless you employ interpolation to hide the discrete physics updates. Which will introduce some latency itself.

As for what most people use as their timestep: It really depends. If you have a really simple simulation with slow moving, big objects you can get away with a much bigger timestep than you would use for complex simulations involving stiff springs, like in a car suspension for example.

you can solve this by not running at a fixed timestepi run everything using floating point timesteps then it HOPEFULLY doesnt matter what your "update speed", or any speed isall that matters is the precision level you choose to use, and the precision of the timeryou'll still have to cap the difference between previous and next to avoid jumps in physics when the system stalls for whatever reasonbut you can't get smoother than floating point...

now you can just multiply everything (including floating point counters) with time_d_factormovement_scale isn't a good name for a variable.. it's just a measure of how big you want your multiplier to be (so that it makes sense in your physics department)for example if its 0.01 you'll measure things in 10ms and so on

so, i'm just posting it here in hopes someone will discount or confirm my idea..this has worked well for me for a month or two now, and it's been very smooth

Variable-length time-steps are an option -- pretty much all of the commercial games that I've worked on have actually used variable-length time-steps -- however, they do have some downsides.

* The delta-time value that you're using for this frame is actually the amount of time that it took to process the previous frame. You're using this as a guess for how long this frame will take, but this guess is wrong in the case where the frame-rate changes.If your frame-rate isn't constant, then when it jumps up and down, your animation will become jittery. This is because your estimation was wrong, so you presented an image to the screen where the virtual distance moved doesn't actually match up with the physical time passed. You can alleviate this somewhat by smoothing your delta-time measurements.

* Numerical integration techniques (such as pos += velocity * delta) gives different results depending on your time-step. This means that, for example, you may be able to jump a particular obstacle at 60FPS, but not at 30FPS, or vice versa! You can actually see this in some COD games, where you can jump to supposedly inaccessible places if you boost your frame-rate to 500FPS...You can alleviate this by using better integration techniques, such as RK4 instead of Euler's method. However, if you're doing accurate physics, you pretty much have to choose a fixed time-step in order to get reliable results...

IIRC Bullet supports variable time-steps, but sternly warns against using them. However, it's possible to have some parts of your game run at a variable time-step, and other parts (such as your physics) run at some fixed time-step.

Just to emphasize what Hodgman said, variable time-steps are discouraged at all costs due to instability and inconsistency issues.Generally every physics simulation can roughly handle variable time steps, but in the world of computers there is literally no way to prove neither network consistency nor replay consistency with variable timesteps.The only way to ensure this is with certain limitations imposed on both the update time and the floating-point model currently active, and in regards to the update timings a fixed number must be assigned.

Variable-length time-steps are an option -- pretty much all of the commercial games that I've worked on have actually used variable-length time-steps -- however, they do have some downsides.

* The delta-time value that you're using for this frame is actually the amount of time that it took to process the previous frame. You're using this as a guess for how long this frame will take, but this guess is wrong in the case where the frame-rate changes.If your frame-rate isn't constant, then when it jumps up and down, your animation will become jittery. This is because your estimation was wrong, so you presented an image to the screen where the virtual distance moved doesn't actually match up with the physical time passed. You can alleviate this somewhat by smoothing your delta-time measurements.

* Numerical integration techniques (such as pos += velocity * delta) gives different results depending on your time-step. This means that, for example, you may be able to jump a particular obstacle at 60FPS, but not at 30FPS, or vice versa! You can actually see this in some COD games, where you can jump to supposedly inaccessible places if you boost your frame-rate to 500FPS...You can alleviate this by using better integration techniques, such as RK4 instead of Euler's method. However, if you're doing accurate physics, you pretty much have to choose a fixed time-step in order to get reliable results...

IIRC Bullet supports variable time-steps, but sternly warns against using them. However, it's possible to have some parts of your game run at a variable time-step, and other parts (such as your physics) run at some fixed time-step.

wow nice writeup! thanks.. i had no idea other people used thiseverything i found on the internet was fixed timestep, and yes i had a huge nagging feeling that i was measuring the previous framebut i couldn't find any reading material on it

Also what may be important is that you give impression responsiveness. For example, if your FPS character is controlled by mouse, it is quite important that the mouse events are processed as soon as the arrive to change the characters orientation to get the feeling of responsiveness. Even if your simulation is running at 30 fps for example, you can update your player directions as often as you draw a frame.

I think I really need to clarify how my timestep works for example at 60 fps the physics engine will simulate 1/120th of a second twice per frame. The time required to render the last frame is divided up into intervals of 1/120th of a second and it processes 1/120th of a second that many times. So at 30fps it will do 4 updates per frame. What I'm really looking for is a better model for updating my physics. As for a definition of responsiveness it is how quickly the simulation reacts to input from the user. Stutter is when the framerate remains constant but motion appears to stop or slow down for fractions of a second I assume this is caused by the physics engine taking longer than the timestep to compute the update.

Edited by ic0de, 23 November 2012 - 12:01 PM.

you know you program too much when you start ending sentences with semicolons;

By default, Bullet physics simulation runs at an internal fixed framerate of 60 Hertz [...] application might have a different or even variable framerate. To decouple the application framerate from the simulation framerate, an automatic interpolation method is built into stepSimulation

So it appears that the Bullet guys do not deem 60 Hz inacceptable at all. The Wiki seems to assume that something 5 to 10 times slower and interpolating is mighty fine for most people to use, though.

if your FPS character is controlled by mouse, it is quite important that the mouse events are processed as soon as the arrive to change the characters orientation to get the feeling of responsiveness. Even if your simulation is running at 30 fps for example, you can update your player directions as often as you draw a frame.

I disagree. Handling input can’t be done asynchronously this way. In order to maintain logical flow, there is a very specific time and place where input is handled, and it is always within the logical loop.

Since it is inside the logical loop, people such as kunos are correct in pointing out that increasing the resolution of your logical update is one way to get increased “response” from your input handler, but it is the wrong way.Of course increasing your logical resolution will invariably help to smoothen your input flow, but excessively sensitive input flow is only necessary in the most extreme cases, such as racing games or fighting games. Since 95% of all games are not this sensitive to input, stutter 95% of the time indicates that there is some kind of underlying problem with the input handler.

I didn’t want to go into this measure of detail until the topic-poster needed it, but the basic idea (again I am leaving out details until proved necessary) is that the logical process will happen every “certain amount of logical time” which has no correlation to real time, except that it can not go faster than real-time.Because of that constraint, the amount of input that can be processed in a single logical update is also supposed to be limited.For example, you see your game lagging and you start waving your mouse around. The mouse commands sent to the engine are as recent as real-time—that is there are enough mouse commands to handle from the start of the logical update (whatever time-stamp that is) until the actual real-world time-stamp.It doesn’t make sense though to actually eat that whole buffer if the logical update is only a fraction of the way from its starting point to the real-world time.Each input needs to have a timestamp, and each logical update should only consume as many inputs as were created during the span of that input.In other words, it must be as follows:-> Last frame ended at t=90, but the real-world time now is t=2,000.The update interval is 30, so I need to perform 63 updates.My first update goes from t=90 to t=120, but the input queue has inputs from t=90 to t=2,000.If I eat them all in one update, I am obviously doing it wrong.-> -> Request and process only inputs from t=90 to t=120. This is correct.Within this same cycle I will be processed 62 more times, and I can eat inputs incrementally until then, at which point I will have gotten them all.

The resulting output is virtually the same no matter what your update speed is. Notice that I said “virtually” here. Every update speed will yield a new result, but humans can’t notice the difference in those results except in extreme situations such as racing simulations and in fighting games.On the other hand, computers can notice these differences, so any networking games must absolutely ensure the same strict simulation on all platforms, which is again why it is bad to pick an update resolution that is any larger than it must be, and also one that is variable.

The update resolution should always be the absolute minimum necessary for proper functioning of the game (aside from my own suggestion, there is a citation on this, but I am annoyed to report that I can’t find it right now).This was the basis behind my original controversial sentence that such-and-such update timings are not acceptable. You should always think critically as to whether or not you actually need X resolution, and generally you should have both smooth input and stutter-free graphics at almost any update resolution, so if you experience stutter or friends at any resolution you should probably be looking at other parts of your engine. Of course there are cases where the only solution really is to increase your update resolution, but these are fairly special-case and advanced, and anyone whose solution really is this should already know the concept of update interval very well, so this is not the case here.