HII in XP: nearly 100% CPU usage

[woodtreeYJ]

I recently installed HII on XP to play the classic game (complete version). The game runs fine, but when I checked the CPU usage, HII was using all nearly 100% all the time. Wondering if anyone has experienced this, and if so, does anyone have a solution?

[Kristo]

I've never checked the CPU usage for that game so I don't know what should be considered normal. Granted, using 100% CPU is not necessarily a bad thing. Is it interfering with your ability to run other programs? What about when you minimize the window?

[Pol]

The game is written like that so it will always report 100% processor usage. However it's not true.
(Or it's true but the priority is very low, it doesn't hindrance the other programs though, not much noticeably. )

[woodtreeYJ]

I don't think the 100% CPU usage is a hindrance to running other programs; however, it does seem to interfere with running HII itself, with visible lags when I move heroes, move creatures, etc. The latter isn't really intended, right? I certainly don't remember it lagging the game itself back when I was running windows 98 with a much slower CPU. Also, running it in windows vs full screen doesn't make a difference, and minimizing it doesn't decrease the CPU usage.

[Pol]

No, that should not happen. Game by itself should be running smoothly as well as other things. I'm coming out of fact that this is normal behaviour in H3 "fake" 100% processor usage. And I think that I remember it from H2 too and even more extensive (ie real).

If it's hindrance the game itself something is wrong. Perhaps trying to switch off the music and checking if that is having any effect? Looks like it's hitched on something.

[Angelspit]

The game is written like that so it will always report 100% processor usage.

Really? Why did they do that?

[Pol]

I don't have an exact idea. Just sometime watch H3 or H2 processor usage. It will always report 100%. However, as I mentioned earlier, it's not true. It looks like the game is grabbing all CPU time simply preventively.

I guess better explanation may come from someone programming high processor demanding applications. About, how exactly this is realised.

__________________________________________
I wrote my first program in BASIC, on our Atari 400, at age 3:
10 PRINT “DO YOU WANT TO GO SWIMMING DAD?”
20 GOTO 10
--Will Woods

[MistWeaver]

The game is written like that so it will always report 100% processor usage. However it's not true.

Err.. what ?! H2 (and H3 AFAIK) are realy taking 100%, and its true. Thats probably because someone at NWC didnt do his "threading in win32 platform" homework. Or maybe, just ugly design. The reason why its not vastly affecting other applications - is it's normal priority.

H4, works correctly though

[Pol]

Why did they do that?

An omitting probably. Or some generic error of IDE in which were both games created. Thinking over that, it looks quite likely.

We may sort that into funny unknown facts, along with extra tavern's hints.

[MistWeaver]

Why did they do that?

An omitting probably. Or some generic error of IDE in which were both games created. Thinking over that, it looks quite likely.

Cmon, what IDE (if its for Integrated Development Environment) could possibly do with that ? Its just their main loop is unefficient.. doing stuff that is unnecessary like redrawing screen even when it does not need to be redrawn.

[Pol]

That is. Let me guess old custom IDE?

Most probably problem is as follows, main executable is spawning several inner processes, which, completely untrackable, are waiting on themself. As we are know, waiting is full time job. So if one of them is constantly waiting on the impuls it's actually taking full CPU time.

Even if in the reality only some negligible cpu time would be required. That to the spells of old and not well optimized applications. I can only sigh, if that would be the only one doing it...

doing stuff that is unnecessary like redrawing screen even when it does not need to be redrawn.

I don't think that this will be the case. That would be seen drastically on the resources consumption. It would hog other applications quite effectively.

[MistWeaver]

That is. Let me guess old custom IDE?

So ? Its the programmer's job to manage threads. In win32 its done by using win32 thread api no matter what IDE you use, and there is no such error, as we know.

Most probably problem is as follows, main executable is spawning several inner processes, which, completely untrackable, are waiting on themself.

- For background work, main executable creates threads, not processes.
- why they are "completely untrackable", if it is a person who manages them ?

As we are know, waiting is full time job. So if one of them is constantly waiting on the impuls it's actually taking full CPU time

That is totaly incorrect. The whole point of "waiting" - is to freeze execution of a thread, thus stoping using CPU time until its resumed. When thread is waiting for the impuls/object/signal/whatever - it costs nearly nothing to CPU. And task bar would show "0" in CPU column for this process(if it is the only thread in it).

doing stuff that is unnecessary like redrawing screen even when it does not need to be redrawn.

I don't think that this will be the case. That would be seen drastically on the resources consumption. It would hog other applications quite effectively.

How you then explain that I can watch cartoons in windowed player and check my email in other window at the same time, and CPU would be still on 10% ? (As we know player window is redrawn ~25 times per second. )

[Pol]

So ? Its the programmer's job

Many companies are using IDEs and other predone stuff to easier theirs task of delivering final product. Although you are right, tweaking this isn't worthy of additional work investment.

- For background work, main executable creates threads, not processes.
- why they are "completely untrackable", if it is a person who manages them ?

The processes created for background work are called threads. That's to be said, here is however no need to going into details because it doesn't help in explaining the trouble.

Some threads can be seen. Some cannot - they are hidden. This is likely the case.

That is totaly incorrect. The whole point of "waiting"

This is totally correct. At least in way how it's probably done in H3. Waiting means that the subprocess it's asking every defined time interval if anything happened. It may be further complicated by time synchronization.

thus stoping using CPU time until its resumed

That's the ideal scenario. In practice it may not works so smoothly.

How you then explain that I can watch cartoons in windowed player and check my email in other window at the same time, and CPU would be still on 10% ?

And point is?

You could be surprised what can cause intensive redrawing or any other big resource misuse, it slow down everything ten times, hundred times ... a lot!

Hehehe. I had been waiting on your comment.

PS on 10% Certainly it will not, more of CPU power is required in Windows environment. Cause it's not so well designed. But it will report only these 10%. The stats from Task Manager aren't, heh, I will finish it with just aren't.

[MistWeaver]

The processes created for background work are called threads.

No, processes never called threads, at least not in Windows. Because these are different things.
Example: Explorer.exe - one process, but we can open many "My Computer" windows - and all of them are threads in the single Explorer.exe process. Just check the task manager.

trusted source (you know, those guys that actualy wrote the system):
http://msdn2.microsoft.com/en-us/librar ... S.85).aspx

This is totally correct. At least in way how it's probably done in H3. Waiting means that the subprocess it's asking every defined time interval if anything happened. It may be further complicated by time synchronization.

Nice.. "totally correct".. but "probably".
And I dont even care about H3 here. Im correcting your absurd statement that "waiting on the impuls it's actually taking full CPU time"
Its not. Just run this most simple threading example:

Code: Select all

while(1){
    WaitForSingleObject(obj, INFINITE);
}

And tell us all, how much CPU time this process will take, untill you release it with PulseEvent or other corresponting to wait object, function.

If your conjectures were true, multitasking would be useless.

That's the ideal scenario. In practice it may not works so smoothly.

This is not "ideal scenario", this is how things work. See above.

Many companies are using IDEs and other predone stuff to easier theirs task of delivering final product. Although you are right, tweaking this isn't worthy of additional work investment.

We're still talking about C++ right ? H2/H3 (H1/H4/H5) were written in it. And no, not in Borlands "Builder", which, I guess could have "components" for anything, not just threading.

Some threads can be seen. Some cannot - they are hidden. This is likely the case.

Thats just WOW... They cannot be seen ??! Is there some kind a black hole to parallel universe in Windows ? You dont know anything about processes&threads, do you ?

To see the invisible, just add "Thread Count" column to your Task Manager

And point is?

Point was to show you that constant window redrawing is not necessary has heavy resource consuming.

PS on 10% Certainly it will not, more of CPU power is required in Windows environment. Cause it's not so well designed. But it will report only these 10%. The stats from Task Manager aren't, heh, I will finish it with just aren't.

Really ? And why is that ? And by your logic, when task manager shows 100%, this means its actualy on 150% ?
Windows uses far less than 1% of CPU when idle, just like any OS should. Otherwise its not OS, its cr*p

[Pol]

I will try to cut it down.

No, processes never called threads, at least not in Windows.

That doesn't matter. Programs are based on many processes and subprocesses optionally. Thread is just one of the processes which is having separate, well, thread. This terminology isn't based on any OS and it maybe in contradiction with some others (terminologies). Actually is just how you call it...

And I dont even care about H3 here. Im correcting your absurd statement that "waiting on the impuls it's actually taking full CPU time"

Do not correct me. This method is possible and was used. Although it's going to fall into the abyssm of history, such errors still happens. (jump down to see how.)

Its not. Just run this most simple threading example:

Wrong example. We are not even need to talking about C++ exactly. Browse a bit into linux kernel and you will see some parts of it having still similar behaviour (Tickers). Emphasis on similar.

If your conjectures were true, multitasking would be useless.

I'm talking about one program. Not about whole OS. That is different level. Yes, ineffecient program in even most efficient OS will be still bad.
(And it can plague OS multitasking.)

This is not "ideal scenario", this is how things work. See above.

Truly not.

We're still talking about C++ right ? H2/H3 (H1/H4/H5) were written in it. And no, not in Borlands "Builder", which, I guess could have "components" for anything, not just threading.

No. We are talking on an thin ice about tools which were used to create the game. You cannot just simplify it to C++.

Thats just WOW... They cannot be seen ??! Is there some kind a black hole to parallel universe in Windows ? You dont know anything about processes&threads, do you

Looks like you are bumping into the terminology once again. With that you can see only threads which were intended to do. Alas threads from the viewpoint of OS. They may not match all what program created. That's why I called them processed and not threads originaly. It still may be the better term, sorry this is really not my parquet. Maybe we can reduce it just to procedure.

Is there some kind a black hole to parallel universe in Windows ?

Yes, and not only one. Even they possibly lead only to crash screen and not any multiverse space but it would been an interesting idea. Windows are having holes, they are constructed with them, let say purposely. However they should not matter for any normal run.

To see the invisible, just add "Thread Count" column to your Task Manager

Redo: Hmm, here. That's useless - here's no need to count the threads. But see them instead. I'm using Process Explorer, free and much better.

Point was to show you that constant window redrawing is not necessary has heavy resource consuming.

Ah, k. Point taken. My was to show you that bugs can do that so they do not relate.

Really ? And why is that ? And by your logic, when task manager shows 100%, this means its actualy on 150% ?
Windows uses far less than 1% of CPU when idle, just like any OS should. Otherwise its not OS, its cr*p

Cause it's inaccurate. Both, processor and memory report. You will not see the peak. And in fact here is no reason for you to need to knowing it. If here would, you are supposed to use logging tools.

Inaccurate doesn't means that you could add a fixed percent value to your original value and correct it. But I guess that you know it.

The values reported by Task Manager are not exact. Or in other words exhausting. Nothing of that. (Nor first nor the second.) It's just simple service tool.

So to summ it up:

And I dont even care about H3 here. Im correcting your absurd statement that "waiting on the impuls it's actually taking full CPU time"

Waiting can take full CPU time but it's unlikely to be reported like that. It's the asking part what is causing the reported heavy load. It's like a server synchronizing with atomic clocks every microsecond. > Too often.

Again back to the waiting, this is also depending on how is that treated in processor. A classic method was that even if computer is not doing any activity processor is still running on full in empty cycles. Thus so much to the waiting. Here's more implications than the one on which you are persisting. This is however very ot.

--

To return back to topic, any idea how to reduce "lags" in H2, how was asked in the original question?

[woodtreeYJ]

Cool information that I am learning here, but back on topic for just a moment, disabling music didn't help, any more suggestions?

[MistWeaver]

Cool information that I am learning here, but back on topic for just a moment, disabling music didn't help, any more suggestions?

100% CPU load is normal for heroes2/3. What kind of lags you have ? Even, irregular ? Is there any sound/music skips ? Is there lags during intros ?

That doesn't matter. Programs are based on many processes and subprocesses optionally.

That is an ok definition for "Computers for Grandma" book. In any tech book, processes and threads are different things. As they actualy are:

Waiting can take full CPU time but it's unlikely to be reported like that.

Nonsense. Read about process planing, quantums, context switching and "Idle process". Its far more complicated than you think, however waiting processes in this system - do not take anything from CPU.

Do not correct me. This method is possible and was used. Although it's going to fall into the abyssm of history, such errors still happens.

You said "waiting is full time job" There is no "if" or "when", so you ment "always". So here Im saing an obvious again: in Windows(Linux/MacOS) individual process waiting is not a full time job. Otherwise it would make the multitasking technology itself - useless.

Wrong example. We are not even need to talking about C++ exactly.

Where you even listening ? C++ has nothing to do with it! I can show you example in ASM or VB or C#, if you like. It all about multithreading in current OS, not the language. And why is it wrong ? Want a proof ? Run this example, open Process Explorer, add Context Switches column, and see how its not changing. Why ? Because OS does not give this process any CPU time!

Another example. Take 2 processes. Both are doing hard important calculations. They have to share CPU, lets say they have equal priorities, so they share it 50/50. Then 1st process calls Wait or Sleep .. whatever. By your logic 2nd process would still be getting 50%, because Waiting in first one still using CPU during its waiting state. But no - 2nd one will get 100%

I'm talking about one program. Not about whole OS.

Program = process. OS handles how processes get their CPU time.

No. We are talking on an thin ice about tools which were used to create the game. You cannot just simplify it to C++.

Well H3 was made in Microsoft Visual C++. And H2 was build using Microsoft C++ compiler. Even without MFC, so I guess there where no additional libs for threading. Just direct API calls.

Cause it's inaccurate. Both, processor and memory report. You will not see the peak. And in fact here is no reason for you to need to knowing it. If here would, you are supposed to use logging tools.

Inaccurate doesn't means that you could add a fixed percent value to your original value and correct it. But I guess that you know it.

OS in idle state (just basic process running like svchost/explorer/etc) actualy has not much to do. Modern processors are pretty powerful, so I cant imagine where those megaflops would go in idle state.

And lets change it a little bit. Now I will talk more, and you'll get some proofs to your theories. Lets start with process that in wait state making 100% CPU load. In windows or linux, doesnt matter..

[Pol]

Modern processors

I will just comment that last one quote.

> Modern <

The H2/3 game is certainly not and processors in that time weren't either. In these times waiting was realised as I stated. And even today is, if something is not working.

That seems like a root of a trouble. You are, hmm, modern idealistic.

I like you idea of "Grandma Book." Yes, I really do. I don't think that all people are normally differ these terms, certainly not here so I tried to be widely understandable. Call it subprocess or whatever you want.

Thread - is visible, system manageable subprocess of some program. The H3 core is not having any thread in that sense, because itself it's already thread. But yes, thread can be having other "threads" which are procedures, calls, etc everything what is program doing and it can be divided by its purpose and meaning.

On that level one of the procesess is amply waiting on the other one input doing it by way, which is causing this hot CPU use report. I think that is waiting or, more exactly said, synchronizing. Or not. It's just a hypothesis which I see like a likely myself.
(I know H3, so redrawing is not likely to be the case, based on my experience. Game is relatively lazy to redraw. Any loop will make it too, of course.)

However the reported load is fake. Because it's reserved CPU time and not really used. Ever.

Nonsense. Read about process planing, quantums, context switching and "Idle process". Its far more complicated than you think, however waiting processes in this system - do not take anything from CPU.

It's not like I would be disagreeing with you. But you are on the different level. You are talking about how is that arranged in OS. Totally unimportant, we are one level up, in the concrete program.

You said "waiting is full time job" There is no "if" or "when", so you ment "always". So here Im saing an obvious again: in Windows(Linux/MacOS) individual process waiting is not a full time job. Otherwise it would make the multitasking technology itself - useless.

Right. It would obsolete the multitasking, that is why I mentioned it first time. However here is if. (And was) > If something is done wrong. Again I'm not discussing normal state of the system.

Why ? Because OS does not give this process any CPU time!

Another example. Take 2 processes. Both are doing hard important calculations. They have...

Still on wrong place.. this is OS level. Not a program.

Program = process. OS handles how processes get their CPU time.

Nein! OS can handle only correctly written programs. Programs which are delibarately written to obfuscate or trick the OS are avoiding such control. The same can apply for some programs just badly written, although OS have ultimate upper hand in this scenario.

Well H3 was made in Microsoft Visual C++. And H2 was build using Microsoft C++ compiler. Even without MFC, so I guess there where no additional libs for threading. Just direct API calls.

It's thin ice for me, because I don't know in which was written H2/3. And I assume that you also don't know it with all gore details.

Modern processors are pretty powerful, so I cant imagine where those megaflops would go in idle state.

And lets change it a little bit. Now I will talk more, and you'll get some proofs to your theories. Lets start with process that in wait state making 100% CPU load. In windows or linux, doesnt matter..

Again my example was for old times, I will not arrange such an experiment. As best suitable for it would be processors around the time of H2/3. (Pentium-PentiumII.)

--

100% CPU load is normal for heroes2/3. What kind of lags you have ? Even, irregular ? Is there any sound/music skips ? Is there lags during intros ?

He said movements of heroeas are shaky.

Unfortunatelly I don't have any idea how to resolve it. If you computer is powerful enough, which is likely, then it looks like that is hanged on something. Here are only two interfaces, which can be suspected as first. Sound and graphics. Decrease theirs acceleration (Hehe, this is really possible. Visit Control Panel > 1 Sounds and Multimedia > Audio > Advanced > Performance > move slider back about one or two pieces .. 2 Display > Settings > Advanced > Troubleshooting > same operation like above.) and see if that helps, or update, change settings in your drivers. Here is certainly high possibility that one of your driver's future is slowing this game. Hard to guess which one, from the water.

[woodtreeYJ]

100% CPU load is normal for heroes2/3. What kind of lags you have ? Even, irregular ? Is there any sound/music skips ? Is there lags during intros ?

The game uses 100% CPU from the very beginning, as expected from the discussion here. However, when I am in games, I get split second lags when I issue commands, especially noticeable when I move heroes, move creatures in battles, but also a little bit when I change screen. There are no noticeable sound/music skips (and turning them all off doesn't help).

[woodtreeYJ]

So a combination of decrease the acceleration and disabling music/sound effect, along with turning the channel to midi, seemed to do the trick (game no longer lags), although it feels kind of sad to play without the sound =(

Thanks for all the help so far. If anyone has any more suggestions for maybe playing with the music on, that would be appreciated also (my video and sound drivers are up to date).