# Fixed timesteps - frame-rate-independent methods

This topic is 4623 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm new to physics, and read in this forum FAQ that I should figure out a way to achieve frame-rate-independent movement. After searching I came on this link on fixed timesteps. http://www.flipcode.org/cgi-bin/fcarticles.cgi?show=63823 I'm sorry but I don't understand some parts of this article. If someone could clarify it ?? Is it a "deprecated" article?

//(time1 - time0)  TICK_TIME... no operator between these 2 statements ???)

while ((time1 - time0)  TICK_TIME && numLoops < MAX_LOOPS)

....
....

//What does that mean ? update graphics here ?
GameTickRun();

....

//Really I don't know
IndependentTickRun(frameTime);

...

// ???
GameDrawWithInterpolation(percentWithinTick);


If I understand well, by doing this fixed timestep I will be able to do physics calculations without worrying about frame rate ?? What are the other frame-rate-independent methods ? Is there anything simpler ? Thanks

##### Share on other sites
By fixing the time step, you can simplify your calculations dramatically. The idea behind this one is to do a pseudo-variable frame rate.

If you expect 60 fps, and you do timesteps of 1/60 of a second, but the computer can only run the game at 30 fps, then to fix this problem, you could just step twice in each 1/30 of a second to get the same effect as having stepped once in each 1/60 of a second.

The other approach to the problem is making a game using a variable timestep. The advantage of that is that you only step once per frame.

Why is it an advantage? When your games get complicated, often the amount of time spent doing the physics calculations is quite significant, so you get a kind of problematic feedback loop with fixed timesteps, because you'll have a drop in frame rate, and then you'll do two or three timesteps, which takes longer, then the frame rate drops even more, and then you'll do four or five time steps, and so on. By doing a single time step, you more or less guarantee that a timestep takes about the same amount of time to calculate regardless of the framerate, so it produces a more stable framerate. The catch is that it's mathematically harder.

##### Share on other sites
time1 = [GetTime];while(true){  time2 = [GetTime];  Update(time2 - time1);  time1 = time2;}

Update(float dt){  [your calcs] * dt;  //ex:  X += X * vX * dt;}

Basically all of your calculations will be multiplied by the time since the last update. So you could run at 30, 60, 300 FPS and your calculations will still be right because dt will change.

##### Share on other sites
Thanks for ur replies guys. They are much more easy to understand.

And is CadetUmfer solution a variable timestep ?

Sorry if it sounds like an absolute beginner, but that's what I am.

##### Share on other sites
Yes, CadetUmfer is giving you a variable time step version. He is essentially using the formula d = r*t to calculate the position of the object so that the object appears to be moving at a constant speed despite the actual frame rate.

The way your tutorial did it using a fixed timestep tries to keep a similar behavior without using d = r*t. For example, let's say you define fixed timesteps at intervals of 0.015 seconds.

So using the same sequence, 0.02, 0.03, 0.01, 0.03, this would happen:

                Real World Time           Game TimeFirst frame           0                       0Second frame          0.02                    0.015        (one timestep)Third frame           0.05                    0.045        (two more timesteps)Fourth frame          0.06                    0.06         (one timestep)Fifth frame           0.09                    0.09         (two timesteps)

The problem, as you probably noticed, is that the game time isn't always in sync with the real time. While 0.05 seconds is pretty minor, it can become distracting if you're playing a fast-paced game. Of course, you can set the timestep to 0.01 seconds and you wouldn't have the problem for this set of numbers, but I was just using 0.015 to demonstrate the issue.

##### Share on other sites
IMO. Variable rate physics is not a good plan. When your physics is slowing down that is exactly the time when you need to spend more time resolving it, not less. When you skimp on your time step in one frame, you pay for it in the next. The idea that double the time step is double the cost is not actually true in my experience.

##### Share on other sites
If you are doing simple physics (for example, constant force or acceleration), then I think it is better to use the method that CadetUmfer posted. It is simpler and more efficient.

In a more complex simulation, the physics can be much more stable and accurate when the time step is constant.

##### Share on other sites
These methods work best when the physics engine is actually able to do a time step almost instantaneously. If your physics engine is so slow (many objects, complex object shapes, lots of collisions....) that it takes a sigificant amount of the frame time, then fixed time step physics can end up slowing your game down to a crawl----the game will always be playing catch up with physics and it never will catch up.

This is not an argument for variable physics time steps (which can exhibit the same behavior). It is an argument to tune your game so that the physics simulation requires a very small fragment of the frame time. And have some protection against needing to run an increasing # of physics steps per frame should you find yourself in the situation where physics needs a bit of extra time once in a while.

##### Share on other sites
OK I'm doing a variable time step.

How do u guys get an accurate time ??

Using cadetUmfer method, GetTickCount() returns something between 21 to 47 at every update. I dont know if it's milliseconds, etc.. can someone tell me?

DWORD time1 = GetTickCount();while(true){  time2 = GetTickCount();  Update(time2 - time1);  time1 = time2;}

To get my FPS I use QueryPerformancecounter, should I use this instead to get the time ?

thanks

##### Share on other sites
QueryPerformanceCounter tends to be inaccurate for anything more than a VERY short burst, so it may not be the best idea to use it.

1. 1
2. 2
Rutin
16
3. 3
4. 4
5. 5

• 13
• 26
• 10
• 11
• 9
• ### Forum Statistics

• Total Topics
633722
• Total Posts
3013549
×