Sign in to follow this  
Juksosah

Fixed timesteps - frame-rate-independent methods

Recommended Posts

Juksosah    130
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 this post


Link to post
Share on other sites
Guru2012    146
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 this post


Link to post
Share on other sites
CadetUmfer    234
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 this post


Link to post
Share on other sites
Juksosah    130
Thanks for ur replies guys. They are much more easy to understand.


About variable timesteps : Any good links, how-to's??

And is CadetUmfer solution a variable timestep ?

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

Share this post


Link to post
Share on other sites
Guru2012    146
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 Time
First frame 0 0
Second 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 this post


Link to post
Share on other sites
billy_zelsnack    174
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 this post


Link to post
Share on other sites
JohnBolton    1372
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 this post


Link to post
Share on other sites
grhodes_at_work    1385
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 this post


Link to post
Share on other sites
Juksosah    130
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 this post


Link to post
Share on other sites
JohnBolton    1372
Quote:
Original post by Guru2012
QueryPerformanceCounter tends to be inaccurate for anything more than a VERY short burst, so it may not be the best idea to use it.


That's a very odd statement. Please explain.

Share this post


Link to post
Share on other sites

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

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this