Trying to understand the XNA fixed time step game loop logic

Question

I came across the blog post Understanding GameTime, and after lots of reading on fixed time steps in game loops this is the approach I would like to take. In summary, this is the logic from the post:

1. Set the desired time spent in Update + Draw as 1/60 of a second (fixed 60 fps).

2. If time elapsed since last Update + Draw is exactly 1/60 of a second:

   • Call Update
   • Call Draw
   • Tick (Game loops.)

3. If time elapsed since last Update + Draw takes less than 1/60 of a second:

   • Call Update
   • Call Draw
   • Look at the Clock (Time left over? Wait.)
   • Tick (Game loops.)

4. If time elapsed since last Update + Draw takes more than 1/60 of a second?

   • Call Update (Until we catch up.)
   • Call Draw
   • Tick (Game loops.)

I guess the two parts I'm having trouble understanding is in #3, how would the waiting be accomplished since thread sleeps are often not accurate enough, and what does it mean in #4 to call update until we catch up? Catch up to what since the time elapsed is already greater than our target 60 fps?

Answer 1

I guess the two parts I'm having trouble understanding is in #3, how would the waiting be accomplished since thread sleeps are often not accurate enough?

Can't answer this for sure as I haven't seen the XNA source code.

MonoGame uses thread.sleep

// NOTE: While sleep can be inaccurate in general it is 
// accurate enough for frame limiting purposes if some
// fluctuation is an acceptable result

From my understanding System.Diagnostics.Stopwatch is likely the highest resolution timekeeping utility you have access to as a part of .net.

What does it mean in #4 to call update until we catch up? Catch up to what since the time elapsed is already greater than our target 60 fps?

Lets say each |----| is a 60hz tick. * is when update is actually called. For some reason a first update took way to long (perhaps it loaded a bunch of new stuff). Basically all 4 is saying is its going to call update as fast as possible with no waiting until the number of times update has been called has caught up to the number of times it ought to have been called optimally .

*       *    *    *    *   *   *   *<---- Caught up here
|----|----|----|----|----|----|----|
0    1    2    3    4    5    6    7