Should have been build-in, but it's a piece of cake to do yourself. A minimum time-step limiter .. when the framerate drops below this limit, the game slows down.
Obviously you shouldn't use the Model.Velocity property anymore when taking this approach, but the same goes when writing your own Collision / Physics library.
I believe if you set a fixed frame rate to your game then deltatime will never go below that rate. But we should also have a built-in guard to prevent deltatime from being zero. Have you run into problems with too small deltatime?
The thing is .. when using a fixed framerate the desired rate is also the time-step limit, meaning that your game will always "slow down" when the desired rate isn't met. While with the solution I posted you can determine a range in which your game uses a variable time-step, while switching to the fixed delta when the framerate drops below a certain number.
+ This is a solution for dealing with delta times that are too high .. not too low ( there is no such thing ).
Was aware of that as well, but it's probably too complicated for most users that they have to recompile the source when they want a limit other then 10fps. Would be ideal if it was a property on App
Agreed! We do need something like this I think
Because for some games, it can be really useful to set a limit, to prevent missing collisions, and stuff.
In the fall of 1972 President Nixon announced that the rate of increase of inflation was decreasing. This was the first time a sitting president used the third derivative to advance his case for reelection.
-=Hugo Rossi=-