Still confused about timesteps in XNA

Question

I have been reading many different posts and articles about timesteps and while I now understand that fixed timesteps are generally considered superior, I'm having a bit of difficulty implementing one in XNA.

Apparently XNA uses a fixed timestep where the update method is called 60 times per second by default. However, I'm not really sure how to reconcile this fact with what I have been reading here, here, and here.

Do I need to supply my physics stepping with some sort of delta variable? Should I even be using GameTime.ElapsedGameTime anywhere in my code?

I guess I'm just a bit confused in regard to how much XNA is actually doing for me. Is it advisable to turn off the fixed timestep in XNA and instead make my own loop like the one from this post?

Answer 1

By default, although XNA tries to work with fixed timesteps, it only uses a best effort policy. Also, later during development, you might want to reduce FPS to 30 or lower (for example, when releasing on X360 or WP7, or after you realize your game is too demanding).

If you implement your game assuming a fixed frame rate, you'd better be damn sure that'll work until the end. Otherwise, adapting to a new frame rate might be troublesome. If, from the onset, you use gameTime.ElapsedTime in your calculations, you can pretty much expect your game to behave as if it worked with fixed time step, but still have future changes covered. The only cases where I can see a real advantadge in using hard-wired fixed time step is when using very precise physics calculations (as stated in your last link) or when relying on discrete time intervals between updates, like a game with a perfect rewind/play mechanism, as Braid.

Regarding the implementation of your own game loop, I think that's more complicated than necessary in XNA. Pretty much everything in the framework is tailored to work within XNA's time step implementation and update/draw loop. You'll have to tinker around, finding out what to remove or keep to get what you want. And if you're not taking advantadge of the work XNA does for you, you shoud really look for a better fit to your specific needs and desires.

Answer 2

Do I need to supply my physics stepping with some sort of delta variable? Should I even be using GameTime.ElapsedGameTime anywhere in my code?

Yes, you should. I'm not sure if XNA have a fixed timestep in 60fps, but even if it does, the fps may drop and you wont be able to do nothing about it, so that's why it is better to still use GameTime.ElapsedGameTime.

Is it advisable to turn off the fixed timestep in XNA and instead make my own loop like the one from this post?

May be a good practice, and also a complicated if you don't know what you're doing. If XNA have fixed timestep, good, stay with it.

Answer 3

FixedTimeStep is about as advanced as you can make such a routine, it gives you (by default) 60 updates a second regardless of if you have 10fps or 100fps, it will also gracefully handle debugging without locking your machine up (the loop you refer to would naively try to catch up to all the lost frames, causing an interesting cascade effect and loss of fps as it jumps the game - possibly all the way to game over screen).

As to if its better or not, that depends on who you ask. For consoles fixed time step makes sense since it simplifies the code and the console has a very fixed potential frame rate. Computer games can be run on wildly varying hardware so those would normally prefer one update per actual frame rendered.

If your not going to code anything "smart" using the ElapsedGameTime (such as running physics in a simpler mode to prevent lag) then technically there's no reason to not use FixedTimeStep. That said, it's easier to convert a game to fixed timestep rather than from it. If you make use of ElapsedGameTime your game will run fine in either mode, where as if you ignore it you can't easily change your decision.

I suggest you read more about how XNA handles this in the words of Shawn Hargreaves himself which should answer most of your questions.

Answer 4

Be aware of FPS drops below 60. Even with fixed time step it will cause issues with your physics/update method. I'd recommend to use GameTime.ElapsedGameTime anywhere in your update/physics code to avoid issues.