//(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);
Fixed timesteps - frame-rate-independent methods
Author
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?
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.
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.
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.
Author
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.
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.
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:
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.
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.
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.
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.
In a more complex simulation, the physics can be much more stable and accurate when the time step is constant.
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.
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.
Author
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?
To get my FPS I use QueryPerformancecounter, should I use this instead to get the time ?
thanks
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
QueryPerformanceCounter tends to be inaccurate for anything more than a VERY short burst, so it may not be the best idea to use it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
