High CPU usage with XNA

8
votes

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 sometimes it works at 60 FPS, but then it just drops to 54 FPS.

I haven't noticed this behaviour before, so I don't know if this is normal. I uninstalled my antivirus and reinstalled XNA Game Studio, XNA Redistributable and .NET Framework 4.

If I set IsFixedTimeStep to false, the game runs at 60 FPS and CPU usage is minimal (1-2%). but as far as I know, this requires me to do velocity calculations using ElapsedGameTime, but I don't know how to do it, since I'm fairly new to XNA. But some say that setting it to false reduces jerky animations.

I already checked this forum thread, but no one has found a good solution.

Has anyone experienced this problem?

EDIT: I did some more research and I implemented a FPS counter (until now, I measured it with Fraps), and my counter shows the game running at 60 FPS (with IsFixedTimeStep = true), so this solves the FPS issue, but the high CPU usage remains. Is it possible that this happens to everyone?

2
c#windowsxnacpuframe-rate
Had this problem too, was giving me a real headache trying to nail it down, since profiling would only tell me the time was being spent somewhere in framework code. Interestingly, if the program is not in the foreground, it continues updating/drawing/running correctly, but CPU usage drops to normal. – Cheezmeister
How many cores do you have? In general the "busy wait" of the game loop while(1) { update(); draw(); } never sleeps (otherwise the game will lag), so you should expect at least 100% of one logical core to be utilized. (so if you had a dual core cpu it should be 50%, dual core with hyperthreading, should be around 25%) – bobobobo

2 Answers

19
votes

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;

What does it mean?

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:

enter image description here

How does this change affect my code?

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.

-1
votes

High CPU usage (100% on one core) is a non-problem for games. In other words, it's expected. The way you're using the CPU when you write a game demands you do this.

Open the code environment and write a simple program

void main(){
    while(1) puts( "aaah" ) ;
}

Open the CPU monitor and see that 100% of one core is used.

Now your game is doing this:

void main(){
    while(1){
        update() ;
        draw() ;

        while( getTimeElapsedThisFrame() < 1.0/60.0 ) ; // busy wait, until 16ms have passed
    }
}

So basically you call update() and draw(), and that takes up most of the 16ms you have to compute a frame (which you will take up most of when your game has a lot of stuff in it).

Now because O/S sleep resolution is not exact (if you call sleep( 1ms ), it may actually sleep for 20ms before your app wakes up again), what happens is games don't ever call the O/S system function Sleep. The Sleep function would cause your game to "oversleep" as it were and the game would appear laggy and slow.

Good CPU usage isn't worth having an unresponsive game app. So the standard is to "busy wait" and whittle away the time while hogging the CPU.