gamer150
July 9th, 2007, 11:18 AM
whenever I run a game I make every instant its CPU usage is 100% is there a way to cut down on this?
Click to See Complete Forum and Search --> : CPU usage
JVene
July 9th, 2007, 11:47 AM
Isn't it ever so?
A great many games do this. Users want high frame rates, and generally developers just let the thing rip through as many in a second as that microscopic city of circuits can manage.
If your graphics are simple enough that you're flipping through 120 to 250 frames per second, though, then perhaps there's something you can do.
I am assuming, too, that your application is constructed in a typical animation loop, and without knowing the overall design of your work, I can only offer some general ideas.
At each cycle of the animation loop, there will be a series of steps you perform that range from repositioning objects, reacting to user input, drawing the primitives, etc.
You can introduce a timing measurement in the loop, and perhaps break the user interface material away from the animation material. This means you would have a UI thread responding to user events (mouse, keyboard, whatever your user is moving to provide input). The animation loop might be a thread by itself, looping. At each loop, if things were done quickly, it could just wait for some brief few milliseconds to keep the frame rate around the refresh rate of the monitor, or slower, but probably at least 30 to 40 frames per second, at your option.
If your game were previously operating at, say, 200 frames per second, this might drop the CPU demand in half or better.
The UI thread wouldn't be serviced in 'hiccups', but with continuous attention by that thread. It could forward input commands to the animation frame, even 'waking it up' from a pause (as described above) to react immediately to a user command (which may not even be required depending on speeds).
This 'delay' I'm suggesting is only applicable if your graphic cycle is so fast that consumption of CPU is excessive (frame rates faster than the monitor refresh are certainly a waste, but framerates between 30 frames per second and the refresh rate are a matter of judgement).
Beyond that, if that's NOT the problem, then either you need 100% usage, or you have some loop consuming resources that should be turned into some kind of thread waiting for a signal.
A great many games do this. Users want high frame rates, and generally developers just let the thing rip through as many in a second as that microscopic city of circuits can manage.
If your graphics are simple enough that you're flipping through 120 to 250 frames per second, though, then perhaps there's something you can do.
I am assuming, too, that your application is constructed in a typical animation loop, and without knowing the overall design of your work, I can only offer some general ideas.
At each cycle of the animation loop, there will be a series of steps you perform that range from repositioning objects, reacting to user input, drawing the primitives, etc.
You can introduce a timing measurement in the loop, and perhaps break the user interface material away from the animation material. This means you would have a UI thread responding to user events (mouse, keyboard, whatever your user is moving to provide input). The animation loop might be a thread by itself, looping. At each loop, if things were done quickly, it could just wait for some brief few milliseconds to keep the frame rate around the refresh rate of the monitor, or slower, but probably at least 30 to 40 frames per second, at your option.
If your game were previously operating at, say, 200 frames per second, this might drop the CPU demand in half or better.
The UI thread wouldn't be serviced in 'hiccups', but with continuous attention by that thread. It could forward input commands to the animation frame, even 'waking it up' from a pause (as described above) to react immediately to a user command (which may not even be required depending on speeds).
This 'delay' I'm suggesting is only applicable if your graphic cycle is so fast that consumption of CPU is excessive (frame rates faster than the monitor refresh are certainly a waste, but framerates between 30 frames per second and the refresh rate are a matter of judgement).
Beyond that, if that's NOT the problem, then either you need 100% usage, or you have some loop consuming resources that should be turned into some kind of thread waiting for a signal.
gamer150
July 11th, 2007, 11:22 AM
they generally go through between 60 and 120 fps
yesterday I was thinking about using multithreading and signals of some sort to somehow solve the problem
yesterday I was thinking about using multithreading and signals of some sort to somehow solve the problem
VladimirF
July 11th, 2007, 01:04 PM
yesterday I was thinking about using multithreading and signals of some sort to somehow solve the problemWhat problem?
You have to answer JVene's big question: are you USING 100% of the CPU or are you WASTING it?
You have to answer JVene's big question: are you USING 100% of the CPU or are you WASTING it?
g3RC4n
July 17th, 2007, 09:26 PM
mabey you could call Sleep(25); every loop or something
codeguru.com
Copyright Internet.com Inc., All Rights Reserved.
Copyright Internet.com Inc., All Rights Reserved.