Game timing in XNA Game Studio 2.0

Originally posted to Shawn Hargreaves Blog on MSDN, Friday, November 23, 2007

In a previous post I explained how the game timing system works when Game.IsFixedTimeStep is set to true:

• We will call your Update method exactly 60 times per second
• We will call your Draw method whenever we feel like it

This is still true in the 2.0 framework, but we changed our implementation of "whenever we feel like it".

In 1.0, things worked like this:

• Call Update as many times as needed to catch up to the current time
• Call Draw repeatedly until it is time for the next Update

In 2.0, the Draw behavior has changed:

• Call Update as many times as needed to catch up to the current time
• Call Draw once
• Wait until it is time for the next Update

In other words, we no longer call Draw more than once without an Update in between. That was a pointless thing to do, as it would just render the exact same image a second time!

Here's why the new behavior is an improvement:

• Consider a fixed timestep game running at 60 fps, with vsync enabled on a 75 hz monitor
• Update completes in, let's say, 3 milliseconds
• Draw completes in, let's say, 5 milliseconds
• This has taken 8 milliseconds total
• 60 fps is 16.7 milliseconds, so it is not yet time for another Update
• We call Draw again
• Because vsync is enabled, the graphics driver waits 13 milliseconds for the next 75 hz retrace
• Yikes! By the time this returns, we have taken 21 milliseconds in total, so we are late for the next Update

In practice the effects of this were very minor, because the next Update would quickly catch up to the correct time, but it caused some unnecessary jitter in the rate of calls to Update.

In 2.0, we call Update at more precisely controlled times:

• Update completes in 3 milliseconds
• Draw completes in 5 milliseconds
• There are 8.7 milliseconds left over, so we wait exactly that long
• Rinse, lather, repeat

Apart from noticing how things now run slightly smoother, how might your game be affected by this change?

The main impact is on games that measure their framerate, for instance using the technique I described here. To take accurate framerate measurements, you should disable vsync and select variable timestep mode. But with the 1.0 fixed timestep behavior, you could still get kind-of-almost-right framerate measurements just by counting the number of Draw calls. With the 2.0 behavior that will just return a steady 60 fps, even if your game is actually capable of running much faster.

Seems like a step backward, huh?

Not really. The thing is, trying to measure the framerate of a fixed timestep update is fundamentally bogus. We want to measure the framerate in order to know how much performance headroom is available. But consider a game where Update takes 15 milliseconds, and Draw 0.5 milliseconds. With the 1.0 behavior we would call Update once, then Draw 4 times, before our 16.7 millisecond timestep was used up. The game thus appears to be running at 240 frames per second. Awesome! That means you have lots of headroom to add new functionality, neh? Not so: your Update method is right on the verge of fitting, and everything will collapse if you make this even slightly slower.

In 2.0, you can't use fixed timestep mode to measure framerate. But you never really could in the first place! It sometimes seemed like this worked using the 1.0 behavior, but would return misleading information.

So how should you measure the framerate of a 2.0 game?

I recommend doing this exactly as before, but also adding a special configuration that will run in variable timestep mode for taking more precise measurements. Here's how you do that:

• Pull down the project configuration combo from the toolbar (the one where you select Debug or Release), and click "Configuration Manager"
• In the project list, click the Configuration column and choose "<New...>"
• Name the configuration "Profile", and copy settings from the existing Release configuration
• Close the Configuration Manager
• Right-click your project in the Solution Explorer, and open Properties
• Select the Build tab, make sure the new Profile configuration is active, and enter "PROFILE" in the "Conditional compilation symbols" box
• In your game constructor, add this code:

      #if PROFILE
          this.IsFixedTimeStep=false;
          graphics.SynchronizeWithVerticalRetrace = false;
      #endif

You can now quickly switch between the Debug, Release, and Profile configurations. Debug and Release will run nice and smoothly, with simple fixed timestep update logic. Your framerate counter will show if you are falling behind the desired framerate, but will not be able to detect how much headroom is available if you are running faster than the target speed. The Profile configuration will just run flat out as fast as possible, which isn't so good for actually playing the game, but provides more useful framerate data.