Hi,

I've been reading about Game Loops and how XNA implements its fixed time step loop vs. variable game loop and have two questions as I'm finding the XNA Framework specifications a bit contradictory.

According to the Game.Draw method specification at MSDN:
Update and Draw are called at different rates depending on whether IsFixedTimeStep is true or false. If IsFixedTimeStep is false, Update and Draw will be called sequentially as often as possible. If IsFixedTimeStep is true, Update will be called at the interval specified in TargetElapsedTime, while Draw will continue to be called as often as possible. For more information on fixed-step and variable-step game loops, see Application Model Overview.

However in the Application model overview it is written:
In a fixed-step game loop, Game calls Update once the TargetElapsedTime has elapsed. After Update is called, if it is not time to call Update again, Game calls Draw. After Draw is called, if it is not time to call Update again, Game idles until it is time to call Update.

This could not be more contradicting. Is a fixed time step game loop calling draw as often as possible or does it call it once and then idles?

1: After some debugging it seems to me that draw is called only once (at most once), am I right?

However I liked deWiTTERS tutorial on game loops (http://dewitters.koonsolo.com/gameloop.html) and would like to use a game loop that has "constant game speed independent of variable fps". The idea is to not waste GPU power by only updating a certain time per second but to draw as many times (using interpolation of coordinates) as possible. This seems to be what the draw method specification actually describes but not what actually happens. So my second question is:

2: how would I best implement a "Constant Game Speed independent of Variable FPS" game loop in XNA?

I have some ideas myself but I would like to know if there is some best practice or if I'm simply wasting my time...

I'm currently in the process of converting my game loop from something similar to something a lot more simple.  I've used that technique in a few games now and found it's just not worth the agro of interpolating (or extrapolating if you prefer) every thing you want to draw.  Now I just have a fixed timestep and all my entities get updated in a single Update.  I found the only non deterministic entities I had was my particle system (which I'm gonna change) and a few effects like bullet trails.

My advice would be "don't bother" unless you really have to.

PS - here't the FlipCode article I based my original loop on:
http://www.flipcode.com/archives/Main_Loop_with_Fixed_Time_Steps.shtml

Shame the site died as there was an interesting discussion about it.

I actually came across your example before and are trying out something similar my self.  Is there some other cons of a  "Game Loop with Constant Game Speed independent of Variable FPS" except the need of interpolation? It seams like the optimal way of designing a game loop for a single thread.

And whats the deal with the documentation specifications, have Microsoft used a "Game Loop with Constant Game Speed independent of Variable FPS" in some previous version of XNA and forget to update the specifications for the Draw method??

Der Konig:

Is there some other cons of a  "Game Loop with Constant Game Speed independent of Variable FPS" except the need of interpolation?

That's a good approach if you want to render locked to monitor refresh rate while supporting a wide range of possible refresh rates (thus tends to be popular with PC developers).

But it's a lot of extra complexity doing the interpolation, and this extra work is unnecessary if you are targetting platforms with fixed, known refresh rates (such as consoles or most modern LCD displays, thus console developers tend to go with fixed timestep).

Der Konig:

And whats the deal with the documentation specifications

This article is accurate.

Thanks, that explains a lot!
Henceforth I'll just save me the trouble and use a fixed time step loop.