cpu at 100% usage in zsnes before picking a game

Kro · Post by **Kro** » Tue Aug 03, 2004 5:00 pm

cpu goes to 100% usage on all the wips i have been able to try, it does not do it in 1.36 official

it happens when you first start it up, and when playing game, it goes back down low

also happens when you press esc during game to get to the menu

this is on a ;
Pentium M 1.6
768mb ram
128mb mobile radeon 9600pro turbo

also a request in same post if possible

widescreen resolutions like 1650x1050, 1280x800 etc would be nice to have, prolly hard to put in though

Magus` · Post by **Magus`** » Tue Aug 03, 2004 5:16 pm

Well, unless it slows the games in ZSNES down, what's it matter? If you need your CPU cycles that badly, just close the program until a fix has been made.

Kro · Post by **Kro** » Tue Aug 03, 2004 6:51 pm

not a problem for me, was just wondering if it was known or not,

only reason i noticed is cause the temperatures jumped from 35 to 50 while going to pick a game

xamenus · Post by **xamenus** » Tue Aug 03, 2004 10:36 pm

Try an optimized ZSNES build by ipher and see if it speeds things up.

http://www.emufanatics.com/emulators.ph ... nfo&id=143 and find the one that says "ZSNES Optimized"

Kro · Post by **Kro** » Wed Aug 04, 2004 12:42 am

speed isnt the problem hehe, it runs great, its just at the menu, you know the purple backround, the main gui

when you start a game it is fine

like i said its not a big deal, just didnt know if anyone had noticed before

Clements · Post by **Clements** » Wed Aug 04, 2004 12:46 am

Yeah, this is a known problem.

Kagerato · Post by **Kagerato** » Mon Aug 09, 2004 4:47 am

This 'problem' occurs in many programs, especially games. In ZSNES' case, there's some loop which is rapidly executing over and over (probably the main loop for the GUI itself). It doesn't really cause a significant performance hit on anything, because as soon as you launch another process that uses CPU time, the Windows kernel begins managing the two effectively enough to have both running at good (perhaps a better word is 'appropriate') speed. This is primarily due to the fact that ZSNES while in the GUI really isn't doing anything significant or CPU-intensive...just a short, rapidly re-occuring loop. When the kernel takes CPU time from ZSNES to give it to some other process, the loop simply doesn't execute as often. No real effect, and nothing to be concerned about.

If you notice...on XP (probably all NT kernel Windows OS) the system idle process is normally doing something very, very similar to what ZSNES does in the GUI looping state.

I have not the slightest clue what (or how much) changed in the GUI's wait-for-input loop after 1.36, but if it were easily possible to go back to the previous behavior without losing any progress, I would imagine this 'bug' would have already been 'solved'.

kode54 · Post by **kode54** » Mon Aug 09, 2004 9:24 am

The problem is that the GUI redrawing and input checking loop is not regulated to a particular frame rate. While events are metered by counters controlled by GUI36hzcall(), the actual loop is not regulated to give up processor cycles while it is waiting.

You can try enabling vsync, but depending on your video card, poor drivers may result in the CPU waiting loop moving to the display drivers inside of the WaitForVerticalBlank() call. (Yes, I realize it must be very inefficient for a driver to be using a wait loop instead of the video card's IRQ signal, assuming it even supports vsync signalling. I've just seen that at least ATI's current and last generation of cards will pretty much lock a program's CPU usage at 99% if they use DirectDraw's WaitForVerticalBlank() method. Very stupid...)

An alternative would be to insert a Sleep(1) into the CheckTimers() function when T36HZEnabled is non-zero, to spare a little processing time.

batchman · Post by **batchman** » Mon Aug 09, 2004 10:33 am

I have another "100% CPU-bug" in addition to the first one mentioned, which occurs when I play any games in ZSNES on my Linux-box (Debian). This doesn't seem to be an idle-loop since it degrades the performance of my computer totally. Normally this wouldn't be a problem, but as it happens I usually run 2-3 thin clients runnig X on the same machine as I'm running ZSNES. Does anyone know of a way to "lock" the available CPU for a certain user? Or do I have to either wait for the bug to be resolved by the authors or do it myself, which I have no time to do...

Thankfull for any thoughts on the subject.