I just noticed today, that when I compile and run a new XNA 4.0 game, one of CPU threads is running at 100% and the framerate drops to 54 FPS.
The weird thing is that so
According to this discussion on XBox Live Indie Games forum , apparently on some processors (and OS-s) XNA takes up 100% CPU time on one core when the default value of Game.IsFixedTimeStep
is used.
A common solution (one that worked for me as well) is to put the following in your Game
constructor:
IsFixedTimeStep = false;
The Game.IsFixedTimeStep property, when true
, ensures that your frame (Update()
, Draw()
, ...) is called at a fixed time interval specified in Game.TargetElapsedTime
. This defaults to 60 calls per second.
When Game.IsFixedTimeStep = false
, the calls to the next frame will happen when the previous one is finished. This is illustrated in the time graph below:
All fixed time calculations (movements, timings, etc.) will need to be modified to accommodate variable time steps. Thankfully, this is very simple.
Suppose you had
Vector3 velocity;
Vector3 position;
for some object, and you are updating the position with
position += velocity;
On default, this would mean that the speed of your object is 60 * velocity.Length()
units per second. You add velocity 60 times each second.
When you translate that sentence into code, you get this simple modification:
position += velocity * 60 * gameTime.ElapsedGameTime.TotalSeconds;
To put it simple: you're scaling the values you add based on how much time has passed.
By making these modifications in places where you perform moving (or timing, etc.), you'll ensure that your game acts as it would back when it was fixed time step.