math & physics
trigger210 at June 28th, 2014 03:48 — #1
I understand that there are two approaches to implementing game loops:
- Variable time step
- Fixed time step
While I understand the implementation details, I'm not sure I understand what the pros and cons for each approach. When should I use one over the other? Are there certain types of games more suitable with one approach over the other? From what I can tell, the fixed time step approach is becoming more popular in most games. Any reason for that?
zet23t at June 30th, 2014 04:35 — #2
Variable time steps are useful if you have simulations that aren't interdependent such as particle systems. If the simulated parts don't take influence on other parts of the simulation, you can be relatively sure that the simulation can be done with variable time steps. Which is useful because variable time step simulation may consume less processing cycles (unless complex calculations are required where simple calculations in succession could be way cheaper).
Fixed time steps are a requirement for deterministic simulations and stable physics simulations. Physic simulations use parameters that are optimized for certain number ranges (e.g. working with certain masses / volumes / forces). Variable time steps can cause these simulations to become numeric unstable. A common observation is that the simulation oscillates and eventually "explodes" when variable time steps are used.
I would always use fixed time steps when the simulated logic is player interdependent or when determinism is required.
sol_hsa at June 30th, 2014 07:09 — #3
Physics simulations are generally integration problems. Using fixed timestep changes one variable to "1", simplifying math a lot. That's the biggest difference, really. And quite often, I wouldn't even want to investigate how to make the integration work right with variable timestep. =)
trigger210 at July 3rd, 2014 04:05 — #4
Thanks for the answers!
Interesting point, but I'm not sure I understand why variable time are needed for this case. What happens if a fixed time step is used for dependent components? There's probably a mathematical explanation to this, but it would be nice to understand the intuition. Thanks!
vrnunes at July 4th, 2014 17:01 — #5
Unless you have a very fast machine that can keep steady 60fps for everything, you should not put all simulations on fixed timesteps. For performance reasons, physics simulation in general runs at a lower framerate and is less smooth than the other simulations running on variable timesteps.
modular at July 6th, 2014 22:48 — #6
You can have your whole game in a fixed 60fps (as @vrnunes sais) loop and be OK. It's very easy approach, only one downside to this is that you might loose flexibility.
By meaning "flexibility" I say for example that either you can do lot's of complex and clever stuff with updating the subsystems. It's a matter of code design mostly that finally is reflected in technical implementation, also it's about practical experience to customize your system according to your preferences.
I remember I read an article on gamasutra once, and there was a guy saying about he was running his artificial intelligence in two different update loops. One in 60 and one in 30 fps, that way he could organize the updating importance much more dynamically and gain many benefits as well from the technical side.
mfdesigner at July 9th, 2014 09:02 — #7
I would suggest fixed time loop exclusively. Fixed time loop allows you to model variable time loop's behavior but not the other way around (simply do things at time epochs of interest and do nothing otherwise.)
If your game allow third party plugin to extend the platform in someway, they may need to add code at fixed time interval. If you start out as variable time loop, you are limited to one scenario only.
just my opinion
vrnunes at July 9th, 2014 14:06 — #8
Variable timesteps exist to compensate for the finite and variable execution speed that (current) computers have. If you put everything into fixed timesteps, in most computers you will either have everything running slower than expected, and/or you will see jerky animations.
Variable timesteps compensate for timing differences, and prevents that. If the game loop is running too slow, it compensates moving more. If the loop is too fast, it moves less. When framerate variates, it does a good job keeping everything as smooth as possible.
Fixed timesteps are generally used for physics, but most of the time people will run physics in much lower framerates, because if we try to run lets say, physics + everything else @ 60fps, most computers won't be able to keep the pace, so it's common to separate both: physics running at low fixed framerate, everything else at variable maximum framerate.
And even the fixed timesteps will probably be adjusted down when the hardware cannot keep the pace. How else could we (today) be sure that the user's computer will have enough CPU to keep the pace? We cannot simply tell "run this in fullhd at 60fps" and it magically obeys, it needs enough processing power to do that, and for most games it won't.
Ok, so there is also the option of calling the update more than one time to try to keep the pace, but then I would call this "variable" as well, not "fixed", as it variates update rate by the elapsed time. That is, when physics is becoming behind, we call it more than one time to keep pace. I did use this solution one time, and it worked well. But I called that variable then, not fixed.
mfdesigner at July 14th, 2014 13:11 — #9
By fixed time step, I mean the system states are updated at fixed time interval. A queue-like mechanism will manage all real time events that are accumulated between time epochs. For slow computers, at each time epoch you will have a lot of accumulated events that need update (such as animations). And in those cases, you can choose to drop events, which result in dropped frames, to catch up to real-time.