@ed022 wrote:
I am suspecting that IsFixedTimeStep is not working properly. My understanding is that, when true, the Game is supposed to run at the specified "framerate". So, for example, my TargetElapsedTime is set to 0.0166666f (that is, 1/60 second), so as to achieve an update/draw rate of 60Hz. Is this the correct assumption?
However, the results I'm observing are - at least, to my comprehension - counterintuitive. It seems to be running the DoUpdate method several times (while (_accumulatedElapsedTime >= TargetElapsedTime)), each with a _gameTime of exactly .0166666 seconds. In other words, it's performing as many fixed-increment updates as possible so that it "catches up" with the amount of real world time that has passed. In the event that it has time to spare, it will Sleep it off until the next fixed time interval.
If I set IsFixedTimeStep to false, then it simply updates once based on how much real world time has passed, and passes in that amount as the GameTime parameter. That is, I'm not seeing exactly .0166666, which is what I would expect. However, this gets called as rapidly as possible, without Sleeping; it does not honour the TargetElapsedTime in any context in which IsFixedTimeStep is false.
What I had expected - what I hope to achieve - is the following. (And, again, I hope I'm presenting logic that makes sense). Here is some pseudocode:
if(_accumulatedElapsedTime >= TargetElapsedTime)
{
DoUpdate(accumulatedElapsedTime); // so I know how much to advance - this is like what happens when IsFixedTimeStep is false.
}
else
{
DoUpdate(TargetElapsedTime); // this is sort of the minimum amount of time that will pass per update
Sleep(howeverMuchTimeRemains); // ease the load of the CPU, much as seen when IsFixedTimeStep is true.
}Does that make sense? Are there any flaws in my observations or reasoning?
Posts: 1
Participants: 1