KEY's games maxing out CPUs?

I recently opened Windows Task Manager while playing Clannad, and realized that it was running one of my CPU cores at full speed... even on the title screen. Then I checked Planetarian -- it was also putting full load on my core.

So I'm wondering if it's a problem with my machine, or with the translation patches, or KEY's programming? (It's not really a huge problem as the games run smoothly, but I'm concerned about my CPU's lifespan) I'm running Win 7 32-bit, on an Intel E7400 processor.

[jyuichi]

One game I have (not by Key though) had that problem so I told it to use only one core (right-click on the process in task manager and select a core) and that fixed it. Its a shot in the dark but it shouldn't hurt anything to try it here.

I run Windows 7 64bit and haven't had this problem with RealLive.

Unfortunately, the same behavior belongs to the most (if not all) of IKURA GDL-based VNs (i.e. everything made by CD Bros relatives).

Whoops, forgot to sign my last post.

I did a bit more digging and found out that RealLive.exe actually only runs at max load whenever there's a menu/gallery visible (title screen, CG gallery, jukebox, save/load slots, in-game right-click menu). CPU activity looks normal when playing the game itself (as long as the menu isn't brought up), and also when I picked a CG (since the rest of the gallery isn't visible). I'm guessing that the application polls for clicks in the menus.

jyuichi, thanks for the tip; I didn't know we can restrict cores before! Unfortunately RealLive.exe doesn't want to cooperate and I get an "access denied" error when I tried it (there were no problems doing that to other processes). I'm curious about your experience though; do you mean you managed to reduce total CPU usage by restricting the process one core only? I would've thought that core would just end up taking over the load from the others.

dsp2003, I haven't played any of CD Bros products. How widespread is IKURA GDL?

[jyuichi]

Originally Posted by Polarem (OP)

Whoops, forgot to sign my last post.

I did a bit more digging and found out that RealLive.exe actually only runs at max load whenever there's a menu/gallery visible (title screen, CG gallery, jukebox, save/load slots, in-game right-click menu). CPU activity looks normal when playing the game itself (as long as the menu isn't brought up), and also when I picked a CG (since the rest of the gallery isn't visible). I'm guessing that the application polls for clicks in the menus.

jyuichi, thanks for the tip; I didn't know we can restrict cores before! Unfortunately RealLive.exe doesn't want to cooperate and I get an "access denied" error when I tried it (there were no problems doing that to other processes). I'm curious about your experience though; do you mean you managed to reduce total CPU usage by restricting the process one core only? I would've thought that core would just end up taking over the load from the others.

dsp2003, I haven't played any of CD Bros products. How widespread is IKURA GDL?

I think it was a CDBros game (it was a JAST/etc title) that I had this issue with. For what ever reason, the game would wig out and suck up 99% but if you set it to one core it had normal usage.

Are your menu's patched? It might be some bad coding on the patcher's part. Not much to do about it then but not stay in menus very long...

Originally Posted by jyuichi

I think it was a CDBros game (it was a JAST/etc title) that I had this issue with. For what ever reason, the game would wig out and suck up 99% but if you set it to one core it had normal usage.

Are your menu's patched? It might be some bad coding on the patcher's part. Not much to do about it then but not stay in menus very long...

Interesting behavior with your game there.

Yeah, my menus are patched as I can't read Japanese. As long as the main game is fine I won't fuss too much. :)

[conman]

It's not an unusual screwup in the programming world to constantly loop over the same thing (busy wait) and not actually do proper idle waiting for input, therefore an application will always use 100% of one core if programmed in this way. I can't say whether your game is doing this or not, but it's a good bet.

Originally Posted by conman

It's not an unusual screwup in the programming world to constantly loop over the same thing (busy wait) and not actually do proper idle waiting for input, therefore an application will always use 100% of one core if programmed in this way. I can't say whether your game is doing this or not, but it's a good bet.

Yea, that's probably it. A shame that it happens, but I guess there's little we can do about it in closed-source software...

[Richard 23]

I've noticed a similar spike in cpu cycle gobbling which really seems to soar when a script error occurs and the interpreter is effectively halted which seems pretty counterintuitive.

Debug mode adds some otherwise unseen menus to the GUI and includes some options for CPU hogging / sharing but I haven't really experimented with them.

To enable debug mode add the following to to GAMEEXE.INI:

; Enable debug mode

#MEMORY=001
#DEBUG_MESSAGE_LOG=001

Attached is an unreasonable facsimile of the menu items that might affect CPU hogging.

R23