It happens to me too (v1.11).
And this is serious issue.

I mean, I can't use my internet browser properly with GalCiv2 in background.

Not that I do that, since games sometimes crashes when doing alt-tabing.

No, the AI does not run until you hit TURN.

Our deal with big oil precludes us from putting in power savings features.

The ship fuel is based entirely off of potato chips.

Our deal with big oil precludes us from putting in power savings features.

George, is that you?

It's like complaining to an ice cream manufacturer that thier product is making your 40-year old, inefficient refrigerator work harder to keep it frozen, and is therefore not a 'green' product.

How about complaining to your girlfriend about shedding too many dead skin cells (90% of household dust) that then gets sucked up by your computer fan necessitating that you clean your computer more often.

If your computer is running so hot as to noticably heat your entire bedroom, I think you have bigger problems to worry about than your new game being such a resource hog.

I have water-cooled video cards and CPU. No heat issues here!

Hah...you think you got it rough with your fancy-smancy computer!
Back in my day we had to sit twenty monkeys in a room with the support staff for a broadway musical armed with catle prods to get that kind of entertainment. I used up so much juice we had to keep the boilers stuffed full of parakeets, or any avian that was available...a chicken will do nicely in a pinch. I remember one day back in '83 I was wearing a hankerchief on my left index finger, which was the style at the time. Blah blah blah.... battle of dunkirk.....blah balh blahity blah marsupials blah blah.

blah-blah
Blah Blah, Esq.

Maybe the 100% CPU is what is playing that theme music that skips all the time because it has to access the hard disk about once every second for some reason.

I think that this is actually the result of using a very typical, accepted, and normal technique for developing software that typically runs with minimal user multi-tasking. If you're familiar with the terms, GC2 is polling the message queue, not blocking on it.

Specifically:

When using a program like Microsoft Word or Notepad, the program is very frequently not doing anything. It has nothing to do while waiting for you to hit the next key, for example. Because there's almost never anything for this sort of program to do that's computationally expensive, the program actually does just not do anything. This is executed, at the most fundamental level, with code like the following:

while(GetMessage(&Msg, NULL, 0, 0) > 0)
{
    TranslateMessage(&Msg);
    DispatchMessage(&Msg);
}

What's this do? It executes the function "GetMessage()" and, when GetMessage() returns with a value that's greater than zero, it translates and dispatches the message. The key here is that GetMessage does not return right away! Rather it sits there, and sits there, and sits there. It may sit there for milliseconds, it may sit there for days. If the program has no incoming message, the program will never ever do anything because it'll sit there waiting inside GetMessage(). With a GetMessage(), the program only runs when it receives a message. If it doesn't receive a message, it doesn't run! That's why your CPU isn't pinned. Whenever you're running a piece of non-trivial windows software, and it's just waiting for some sort of input, it's waiting inside GetMessage() or something similar. It's "Blocked."

Sadly, this doesn't work so well for real-time software or videogames such as GalCivII. GalCivII, even if you never touch the mouse, has to continue updating itself. It needs to run the AI in the background, update video, etcetcetc. And while many of us have the popular GPU, the CPU is still dispatching commands to it. This means that real-time software, like video games, will generally use a message pump like the following:

if(PeekMessage(&msg,NULL,0,0,PM_REMOVE))
{
    TranslateMessage(&msg);
    DispatchMessage(&msg);
    DoSomethingWhileWaitingForInput();
}

Do you see the difference? Instead of "GetMessage()" we used "PeekMessage()"! The difference between these two functions is that PeekMessage will never sit there waiting! That is, PeekMessage does not "Block." Instead it will always return, whether a message was there or not!
That means this loop will always be running at full speed. This is a form of "polling," because the program is constantly "polling" the message queue to see if there's a new message.

This means that our program will continue to run, and continue to update, even if it hasn't received a message, and that's a "Good Thing".

Have you ever had a shareware or free program that wouldn't update until you moved the mouse, even though you thought it should? That's because they used GetMessage and didn't post occasional update messages back to themselves.

GC2's video is very sensitive to timing (as evidenced by the funky bug with multi-core CPU's and graphical "jitter"), so it's not surprising to me at all that they'd want as much control over the timing as possible. And that's what polling with PeekMessage lets them do.

There are lots of resources on the web about this, I stole some of my examples from:

Beating the Message Pump

Documentation for GetMessage() and PeekMessage() can be found on MSDN:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/messagesandmessagequeues/messagesandmessagequeuesreference/messagesandmessagequeuesfunctions/getmessage.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/messagesandmessagequeues/messagesandmessagequeuesreference/messagesandmessagequeuesfunctions/peekmessage.asp

So don't worry, don't panic. (a) This isn't a windows bug. ( This isn't a Stardock bug. (c) This isn't any more non-green than any other modern, intensive game. Even Starcraft did this, e.g.

A case could be made for pausing the state of the game and kicking into an alternate message loop or some such craziness when alt-tabbing to save those cycles, but there are a lot of nasty technical issues and gotchas involved, and getting Alt-Tab to work properly in software like this can be tricky enough as it is.

I have, of course, glossed over a great many technical details, and I've said some things that are just plain wrong for the sake of illustrating underlying concepts. I encourage anyone who's interested to perform further research. Learning the fundamentals of message-based programming can be an intriguing topic if you like that sort of thing.

Good gaming, all!

(Oh! And Stardock! If I ever get laid off, please hire me! I'm not that far away: I went to school in Toledo and am working in Cleveland on process control software right now. )

Well, I am also a programmer and have written some very basic games that do graphical stuff and they still don't run at full CPU. Granted, I have never written anything near like GalCiv II, but I have written 3D games that you could walk around in the landscape and still never had the CPU pegged. Everything was still very fluid.

For those of us on _Laptops_ this is an even bigger problem. Battery life, hot laps, noisy fas, overheating, etc. Really big problem for laptops.

The structure of the PeekMessage pump is one of the things I significantly glossed over for simplicity's sake. PeekMessage returns zero on no messages available, or a non-zero value on messages available. At that point, you're probably looking at a structure more like:

BOOL isFinished = false;

while(!isFinished){
    if(PeekMessage(/*blah*/){
        TranslateMessage();
        DispatchMessage();
    }
    DoNonInteractiveLogicHere();
}

You don't want to do a full sleep on every cycle because (1) You're creating a pause of the same length of time, no matter how long it took to execute your non-interactive (game) logic between pauses and (2) sleep doesn't typically have the sort of fine precision a game like GalCiv2 probably wants.

A more likely candidate would be to take advantage of your OS's services and the structure of the message-queue and have the OS post a message to your game every N (we'll make up a number, say 50) milliseconds. In my own experience, I've generally called such a time unit a "tick". That would make every "tick" a sort of "mini-turn" and, when strung together quickly enough, would result in the appearance of real-time.

This has the added advantage of dealing properly with some ticks that take more time and some ticks that take less time, but introduces potential difficulties wrt synchronization between ticks. For example, suppose you start performing some computationally-expensive action "f" on tick "t". f doesn't complete within the tick, and the message for tick t+1 is received. While f is still working. Does the logic on tick t+1 understand that the logic from tick t may still be working on some shared data structures? How does the logic from t+1 avoid stepping on t's toes and corrupting t's data?

There are solutions, of course, but decisions are made there that can impact how the game's core logic behaves. Given the goodness of GalCiv2, whatever decisions the devteam made, I think they made the right ones.

Now note, I am nowhere near experienced with programming this specific sort of system. My own experience tends toward real-time communication between distributed systems (and I'd consider myself a neophyte in that field as well). My code examples are spur-of-the-moment and not at all guaranteed to be correct or even strictly representative.