Unfortunately I cannot recall where but I definitely read it somewhere, that the use of delta time should be avoided for some reason. Is there really a scenario where controlling animation or other in-game events using delta time is bad or it was just a wierd dream of mine?
\$\begingroup\$
\$\endgroup\$
2
-
3\$\begingroup\$ I cannot recall hearing that ever. If you dont use delta time your game will look like crap if it's not run at the desired FPS. \$\endgroup\$– Green_qaueCommented Jul 5, 2013 at 10:28
-
1\$\begingroup\$ The answer is always yes if you're talking about games. If you're considering numerical simulations, their purpose can ignore the need to synchronize with a viewer application and/or input system. thus the dt you'd feed such a simulation can be fixed and frame rate independent. Like mentioned in elFarto's answer, this is a trait you want to preserve, since variable dt are almost always a source for nondeterministic behaviour (really not game friendly). \$\endgroup\$– teodronCommented Jul 5, 2013 at 10:56
Add a comment
|
2 Answers
\$\begingroup\$
\$\endgroup\$
Using delta time is usually the correct solution. However the issue I believe you're thinking of is using a varying delta time in conjunction with a physics engine. In this case the time step should be fixed for the best/most consistent results.
Fix your timestep is a good resource on the matter.
\$\begingroup\$
\$\endgroup\$
Adding to @elFarto's answer, you should use a fixed timestep for all game logic. You really want AI and such in sync with physics.
You use your frame's delta time to update an accumulator to know when to step your fixed timestep.
You also apply the delta time to interpolation when drawing. A frame must be drawn just before the next fixed timestep. If you just draw the current state, you'll end up with some jitter in movement. You need to store both the "last" state (relevant bits for graphics) and compute one step ahead. You can then look at your time accumulator to see at what point you are between those two steps and draw interpolated values (positions, rotations, animation data, etc.) that represents that time. So long as your fixed timesteps aren't too far apart, you shouldn't see any glitches from the interpolated values, but it will hide any jitter.
The jitter is less pronounced the smaller the timesteps are. For simpler 2D games, you can often set your timesteps to particularly small values (such that every frame typically is 'stepped' many times before rendering). Because the values are so small, interpolation won't be necessary.
answered Jul 5, 2013 at 20:39