Avoiding fixed timestep death spiral?

[airstruck]

@MasterLee, thanks for the comments. I'm now leaning towards using a symplectic integrator most of the time, and then correcting with the code I gave here when "logic" needs to happen (collision, bad guy wants to turn around and move the other way, etc.). Since symplectic integrators should conserve energy and be fairly cheap, I think this will work out well. Only problem with symplectic integrator is higher-order derivatives than acceleration; ideally I'd like to have one order higher for smooth easing (acceleration=2, jerk=-2). This thread has gotten a bit cluttered, I may open a new thread to discuss it if I run into anything.

[bananpermobil]

here's a good article on fixing the timestep. The approach might ease your concerns about devices on the lower end, but like all magic it comes with a cost: interpolating the drawing.

http://gafferongames.com/game-physics/f ... -timestep/

[airstruck]

here's a good article on fixing the timestep. The approach might ease your concerns about devices on the lower end, but like all magic it comes with a cost: interpolating the drawing.

http://gafferongames.com/game-physics/f ... -timestep/

Thanks, but I was really looking for ways to avoid discarding anything from the accumulator, which that article uses as a fallback after processing a fixed number of steps in a row to try to catch up. One solution is to use a single longer step instead of multiple steps at once. Setting things up so that you get the exact same result from two regular timesteps as one double-length timestep is the tricky part, but does work if done properly (precise integration, CCD). This means you can catch up in one longer step if it falls behind, and that long step doesn't take any longer than the normal steps to process, so there is no chance of death spiral and no need to discard any time from accumulator as a safeguard.

In this scenario, steps can be split up into smaller pieces for individual entities when something happens to them in the middle of a step, like collision or AI, while the rest of the entities use the whole step. When simulation does not depend on constant timestep for accuracy, we can get away with this. In fact fixed timestep is probably not necessary at all when doing it this way, but having the longer timesteps always be multiples of the regular timestep helps mitigate floating-point rounding errors. I also scale everything up/down by 3 before/after integrating to further mitigate rounding errors caused by division by 6 in the acceleration part of the polynomial (see previous comments).