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*dtAnd 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.