Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
While looking at the stepping function, I've noticed that we don't have a fail safe algorithm for the fixed update stepping.
A good thing would be have a fail safe algorithm that limit the fixed updates to something like 8.
However if the fail safe algorithm exist, worth mention it anyway, but I would like to see it so I will appreciate if you tell me where I can find it.
This is by design. If your fixed update is taking too long, then you are inherently breaking the design of your game. A fixed update is not inherently a guarantee that an update will run every X seconds - it is a guarantee that the a simulation will be ran at every N interval.
This means that even if your simulation runs slower, or faster, you will always get a simulation step at N interval. This is also why we use accumulators instead of strictly time comparisons. An accumulator allows us to run N simulation steps for every X time, regardless of actual run time.
If your simulation is inherently way too slow for such a operation, then your design is inherently flawed and you should reconsider your execution and/or step interval. I do not believe it is in the best interest of the engine to soften the blow for these situations, as that will then soften guarantees and may cause issues down the line with other simulations.
This is not what I mean, probably my explanation is not enough detailed so let me enrich it.
We have the following execution process:
The first step we have a scenario where the actual DT is 0 so only the Normal process is executed:
The second step we have the DT to 1 so:
The result is that the DT of the next frame is 2 so:
The result again is that the DT of the next frame is 3 so:
The result again again is that the DT of the next frame is 4 so:
And so on....
As you can see without a fallback algorithm that stop it the performances of your application keep degrading because the fixed algorithm is executed over and over again in the same frame.
Usually in real life this kind of scenario happens when you have a bigger DT due from model loading, or window switching. So a single big DT may execute many fixed process triggering the above scenario where you are forced to shutdown your game and reopen it.