Matrix Games Forums

I run it in a window since this prevents occasional crashes after alt-tabbing out. However, I've noticed even with the window minimized the CPU usage is still 30-40% on my HyperThreaded system (which corresponds to 60-80% on a one CPU system). Is this a programming error, or a deliberate use of a polling loop? While awaiting user input in a game, shouldn't its CPU usage be zero? When an app of this sort gets a window minimize event, shouldn't it just go to sleep until the window is restored? As a former programmer this just bugs me immensely.

Unless the game is *specifically* designed to go to sleep when focus is shifted, it will continue to try and run flat out.

Very few games are ever written to do this as it seriously complicates coding.

If you want to drop it down, go into your Task Manager and drop the priority. (this may cause a whole host of other issues)

Most games use a main loop that basically goes like this

While the user didn't quit
Check if the user did something
Deal with it
Update the game state
Update the display (whether or not anything has changed since last frame) -- I suspect that this is the biggest culprit on a game like this

This loop means that essentially 100% of cpu cycles are used by the game

Of course, I have not seen the code and am only guessing based on game loops I have seen.

Don't forget the "play the music" step, it's generally the most brutal of the loop hence all the problems with machines having borderline sound. [;)]

ORIGINAL: Mr.Frag

Unless the game is *specifically* designed to go to sleep when focus is shifted, it will continue to try and run flat out.

Very few games are ever written to do this as it seriously complicates coding.

you are joking? It asks for a line of code or so => if the window message is WA_INACTIVE then disable the threaded timer(s) that run the app... If the message is WA_ACTIVCATE, then enable it (them).

In regards with the post of the first user, if you are playing the game and that the game is "only" waiting for user input then its still normal that the CPU usage is high, thats the way DirectX works, you have to render at each timer tick (aka frame) the screen.

Ah thanks for the insight. So DirectX doesn't let you defer/avoid screen updates when the draw surface isn't visible, eh? Guess windowed mode isn't really given first-class treatment under their programming model. Too bad, since it really is an event-driven game with plenty of opportunity to yield the CPU to other tasks since there's virtually no CPU computation going on 99% of the time while the user is pondering his/her next move. (And playing music doesn't count, that's trivial and not expensive to do.) I'll just have to add DirectX to my ever-lengthening "enemies list" then

no no, if the draw surface is not visible, you can just stop the rendering process, thats no problems. I though you asked why directX still consumed bandwith when the screen was seen but no action except waiting for user input was done (the surface is "maintained" at all time, eg redrawn constantly, whereas in standard windows drawing a surface is redrawn only if invalidated).

As for the app minimized, it is not done for GGWaW not because its difficult, but surely because Gary have not thought it could be of use for somebody (and its true that 99.9% of users dont care about this issue IMHO). [:D]