Drawing vs. Updating and IsFixedTimeStamp (XNA)

Before we discuss frame rate, we need to understand games from an MVC-like perspective.

Game State vs. Game Presentation

You can divide game “stuff” into two things: game state (data, classes, etc. of how things look right now — the current player the level is on, health, position), and your presentation (3D models, lights, textures, sprites, etc.).

Microsoft build XNA with the understanding that these two things are separate, but related. For example, if you have a physics-like simulation, you may want to update the state/simulation several times between calls to Draw. This could be because your users have older hardware, and while they can’t draw things at 60 (or maybe even 30) FPS, they shouldn’t have the game run slowly.

To say that another way, the state of the game and the display of the game should be independent. You want the game state to always, always be consistent and to run “fast,” even if you can’t draw that fast; this means your game will still play at the same speed, regardless of CPU/hardware performance — it’ll just draw less frames on slower computers than on newer ones.

Who Cares, Tell Me About IsFixedTimeStep?

Now that you (hopefully) understand this difference, lets talk about IsFixedTimeStep. IsFixedTimeStep is true by default, which means that XNA calls Draw no more than once every 1/60th of a second. (You can change this frequency if you modify the TargetElapsedTime property.)

That’s what “fixed time-step” means — every call to Draw occurs at the same, fixed, time-step. Because game state is not the same thing as game presentation, calls to Update still occur as frequently as your computer can handle. (Regardless, I suggest you use a semi-fixed timestamp to avoid troubles like fast-moving objects “skipping” through walls.)

This is generally a good thing. It means that your game will run at 60FPS, and not faster. After update calls, XNA will ask, “did 1/60th of a second pass since the last Draw call yet? No? Okay, I’m not drawing anything yet.

This also means that you don’t lose “resolution” in your game state by limiting it to 60FPS.

On the other hand, setting this to false causes XNA to call Draw after every Update. It doesn’t hold back. This means you will eat more CPU cycles, but potentially run a faster FPS on better hardware. Again, it won’t change your game state update frequency, since that runs full-tilt regardless of the framerate.

About Ashiq Alibhai, PMP

Ashiq has been coding C# since 2005. A desktop, web, and RIA application developer, he's touched ASP.NET MVC, ActiveRecord, Silverlight, NUnit, and all kinds of exciting .NET technologies. He started C# City in order to accelerate his .NET learning.
This entry was posted in Libraries and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *