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 timestep
i run everything using floating point timesteps
then it HOPEFULLY doesnt matter what your "update speed", or any speed is
all that matters is the precision level you choose to use, and the precision of the timer
you'll still have to cap the difference between previous and next to avoid jumps in physics when the system stalls for whatever reason
but you can't get smoother than floating point...

if (_localtime - _lasttime(0) > timing_max_difference)
_lasttime(0) = _localtime - timing_max_difference
time_d_factor = 1.0 + (_localtime - (_lasttime(0) + movement_scale)) / movement_scale
_lasttime(0) = _localtime

now you can just multiply everything (including floating point counters) with time_d_factor
movement_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

you can solve this by not running at a fixed timestep

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 [font=courier new,courier,monospace]pos += velocity * delta[/font]) 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.


L. Spiro

[quote name='Kaptein' timestamp='1353674224' post='5003467']you can solve this by not running at a fixed timestep

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 [font=courier new,courier,monospace]pos += velocity * delta[/font]) 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.
[/quote]

wow nice writeup! thanks.. i had no idea other people used this
everything i found on the internet was fixed timestep, and yes i had a huge nagging feeling that i was measuring the previous frame
but 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.

Just my 2 cents, best regards!

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.

It may be worth having a look into Bullet's documentation:

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[/quote]

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.


L. Spiro