CPU Usage

My very simple graphics application also says this, yet nothing else runs slow; so, I'm assuming it's normal because the game is running in an infinite loop (pretty much). I think you should only be concerned once it starts eating at your memory.

It means your application isn't spending much time blocked, so the only other thing it can do is use the CPU. What you should be asking yourself is if your application should be blocking more often so that other applications can use the CPU you don't need.

while(true);

This uses 100% cpu if nothing else is attempting to use it. A game loop is effectively a fancy version of that statement, with a lot of stuff going on that makes it not so obvious that you're grinding away in an infinite loop [your game loop], which means that it will of course use 100%. This is natural. This is good. This means that you aren't doing anything strange that would result in activities that would later manifest in your game as periodic slowdown. You want it to run as fast as possible, which is of course 100%.

The operating system will slice it up [thus reducing it from 100% to something less] if something else wants to use the CPU as well..... you are not causing any problems.

Quote:

Original post by Drigovas The operating system will slice it up [thus reducing it from 100% to something less] if something else wants to use the CPU as well..... you are not causing any problems.

Except on laptops, where you keep the processor spun up in full-power mode even when sitting at a menu screen. It plays hell with battery life, and there is no reason to do it - implementing a real event loop is not hard.

When you are running in menu mode, or other game modes where not much graphics activity is going on, you should consider yielding your application to free up some CPU cycles every lap in your main loop. This both allows other applications more CPU time, but most importantly it saves power and thus gives us laptop users better battery life and quieter computers, not to mention that your are also environmentally friendly.

Yielding is done with the Sleep() function. At least go for a Sleep(0) which tells the CPU scheduler that your process is done for this time quantum. But, if your graphics is not suffering go for even higher sleep delays in your main loop.

This of course only applies to game modes where you are not requiring full graphics performance.

I forgot to tell why yielding is not a good idea when you want full graphics performance. The reason for that is because yielding means that your process is not going to be re-scheduled again until the next time quanta in the CPU scheduler occurs. This is typically in the range between 20-60 ms for desktop operating systems. If you would like your application to run as smoothly as possible you want it to run with at least the speed of the screen refresh rate. If you are running full screen with vertical blanking synchronization you would like your application loop to run with exactly the same speed as the screen refresh rate. Running a screen at 60 Hz means that you want your main loop to run at 16 ms intervals. If you were to yield, this would at best allow your application to run after 20 ms. If you are then running synchronized with your vertical blanking, this would mean that the application would wait for the vertical blanking spending the full 16 ms time, then sleep for another 20 ms, which means that you will miss the next vertical blanking. All this means that your application will now run at best with half the frame rate than it could have done if your did not yield.

So, yield in your main loop when you do not require full frame rate, such as in menus. And do not yield when you need full performance.

I get around the problem by fixing my game step to a particular time (currently 1/240) running it as many times as is required per render to catch up, and sleep the remainder to keep it at 60fps. This target value will actually be left to vsync in fullscreen mode, rather than forcefully sleeping to keep at 60. The sleep itself is actually a ::WaitForSingleObject with a timeout. Everything runs nice and smooth, and I keep quite low CPU usage - Release more so than Debug.