Avoiding fixed timestep death spiral?

[raidho36]

I'm pointing out the flaw in your logic, the assumption that given identical starting conditions you can produce same outcome regardless of update rate. It's simply false, and doesn't even have to do with floating point errors, it's just mathematically wrong. Hence the difference isn't merely within floating point error range and is visible to the naked eye.

[airstruck]

I invite you to read the thread again. Calculating motion using Taylor series expansion instead of an approximation, and not interfering with the simulation by changing the coefficients while it is running, will produce the same output regardless of update rate. The only error at that point is floating point inaccuracy. There is a code example to prove it, which speaks for itself.

Yes, you might want to change things around while it is running anyway; that is a separate problem and there may be ways to work around it. Some of it can become part of the polynomial, and some of it can work by breaking timesteps into multiple parts at points in time where things happen (collisions, AI, etc.).

[MasterLee]

It is correct that regardless of update rate when you done your math correct nothing different will happen. But if not …
But by using variable timestep you avoid the fixed timestep death spiral by avoiding the fixed timestep.
In an discrete World you can't rational timesteps. You can only use integer timesteps so no floating point problems. You could use varialbe or fixed length timestep, best of length one. Variable timesteps will bring some problems and some calcualation will involve new loops so that it might be easier to run an fixed time step multiple times. That is what is done in Simutrans where the simulation steps per second may be different frame the frame per second. Also something to note is some RTS games have an realy low amount of logic steps per second something around five or sometimes even one. But the animation is calculated per frame. So what happening is following it is calculated that the unit move to an new cell this is done instantly now assume we have 60 fps in the coming 12 frames the animation of the moving unit is shown. But that is only moving along an path and can be done using variable length timestep.

By the way when programming games in Windows 95 i was used to separate game logic, input routines, drawing and sound routines in four different threads. Maybe that was relative senseless as most CPU only could work with one or two threads at the same time in that time period. But today where cheap smartphones got multicore it might be more useful.

[raidho36]

I invite you to read the thread again. Calculating motion using Taylor series expansion instead of an approximation, and not interfering with the simulation by changing the coefficients while it is running, will produce the same output regardless of update rate. The only error at that point is floating point inaccuracy. There is a code example to prove it, which speaks for itself.

Yes, you might want to change things around while it is running anyway; that is a separate problem and there may be ways to work around it. Some of it can become part of the polynomial, and some of it can work by breaking timesteps into multiple parts at points in time where things happen (collisions, AI, etc.).

Your application is to make the games not lose synchronization (not by much anyway) when one [hypothetical] instance runs smoothly and the other underruns, correct? I've highlighted that the mere usage of non-constant timestep leads to visible desynchronization, defeating the purpose. Additionally, splitting up timestep to compute integrals with true constant values and functions is a terrible idea: you're already lacking CPU time to compute a single timestep, and you're suggesting to perform multiple.

[MasterLee]

you're already lacking CPU time to compute a single timestep, and you're suggesting to perform multiple.

That is wrong you are lacking CPU because you spend to much in drawing routines.

[zorg]

you're already lacking CPU time to compute a single timestep, and you're suggesting to perform multiple.

That is wrong, you are lacking CPU because you spend too much in drawing routines.

Technically, (at least in the original post,) it wasn't defined whether the logic calculations or the rendering took more time than what was available, only that there was not enough to process one step... though airstuck may have elaborated later on.

[raidho36]

And it doesn't matter whether or not graphics is the bottleneck, you still don't have enough time to process the timestep update.

[MasterLee]

And it doesn't matter whether or not graphics is the bottleneck, you still don't have enough time to process the timestep update.

Nope in build engine for example you have 99% for drawing and 1% for the rest which means you can easily sacrifice one drawing cycle for 99 update cycle.

[raidho36]

I don't think you're on the same page with us, the thread is specifically about dealing with situations where there isn't enough time to process a single timestep - by definition.

[MasterLee]

I don't think you're on the same page with us, the thread is specifically about dealing with situations where there isn't enough time to process a single timestep - by definition.

Nope the thread was about when an single update single draw loop that had not enough time to. And then it was stated that an multi update single draw loop maybe better. But the problem is as old as most of the solutions:
http://fabiensanglard.net/timer_and_framerate/index.php
Update with fixed time-steps becomes only an problem when you sacrificed all drawing cycles.