While developing a simple physics engine to integrate with a Gosu game I'm hammering together, I noticed an issue that might compromise Delta-Time systems.
The current implementation of my simple system is very efficient and can run particle collisions and so on.
The problem is that when I click and drag the window, the Gosu engine pauses, but the Gosu::milliseconds()
counter keeps going up. This makes sense since it should "return the number of milliseconds elapsed" since the Gosu started running.
However, for time-sensitive applications - especially a physics engine handling collisions - this means that certain features may be skipped.
An an example, imagine a free-falling object at position (0,0)
, that follows this equation(source
):position += speed*dt
And it is supposed to hit the ground at, say position (0,100)
. With very small dt
's, as a result of being called in a healthy update loop, this object's animation is very smooth and can easily find the floor at (0,100)
by successional approaching and correcting its trajectory.
However, when I hold and drag the window the updates stop, meaning "position += speed*dt
" is not computed until I let go of the window.
When I do let go though, I will have a very large dt
, as a result of using Gosu::milliseconds()
to get that time delta between that update cycle and the previous one.
Eventually, for sensitive trajectories such as the one mentioned above, this new king-sized dt
can blast the object's position to (0,9456)
for example, which would take it way below the floor without ever having the opportunity to check for a collision.
I tried looking for a solution but it yielded no results.
I was wondering if anyone had looked into this before and was willing to provide some insight. I thought there may be a way of monkey-patching the window class to forbid dragging (which is a solid option in my case), or some kind of lower-level approach that keeps the game loop running even during the window dragging operation.
Any help is appreciated.
Thanks a lot.