Jump to content
Posted 20 October 2012 - 07:12 AM
Posted 20 October 2012 - 07:33 AM
Posted 20 October 2012 - 07:42 AM
Posted 20 October 2012 - 07:58 AM
Yeah. Or Sleep(0) to give up the remainder of my timeslice.
I think he meant to use the sleep function to wait until its time for the next frame?
Posted 20 October 2012 - 08:32 AM
Posted 20 October 2012 - 08:59 AM
Posted 20 October 2012 - 09:07 AM
Posted 20 October 2012 - 02:06 PM
If you're writing a realtime game and want smooth animation, avoid limiting the framerate with Sleep. Use vertical sync in your graphics API instead, which will limit your game to 60 fps if your screen is set to 60 Hz. Usually DirectX and OpenGL nowadays handle vertical sync by sleeping to avoid high CPU usage if your game processing completes with time to spare before screen refresh. Internally they will use some system-level sleep that is made to wake in time for the swap, whereas an application level sleep can cause tearing and stuttering in your animation, as nife87 explained, and you probably want vertical sync anyway to make everything look smooth even if you don't care about sleep.
For casual games and window mode Sleep might be a good choice.
Posted 21 October 2012 - 08:08 AM
Posted 21 October 2012 - 09:28 AM
Okay. I used an event and WaitForSingleObject to wait for a maximum of 100 ms when the game doesn't have focus. Now when the game doesn't have focus it uses up almost no CPU time at all. When nothing is running except windows I have 10-20% CPU usage. The game loop doing nothing at all (I event commented out every single call to update a subsystem) shows 50-60% CPU usage. So my game loop accounts for about 40-50%. What's weird though is that when the game is running logic it stays at just about exactly 50%. Why would this be? I'm doing some more work, but my CPU usage doesn't end up fluctuating as high. Could it just be a fluke and the OS is doing stuff behind the scenes? Or could it be because I send tasks off to other cores with a thread pool?
Posted 22 October 2012 - 05:05 AM
There is a drawback using VSYNC . It will effectively sleep until next sync, which is sometimes fine. Except when your game refresh rate is slower than 60 fps, it will still wait until the next sync, and you will miss a full cycle. 60 fps equals a sync every 16.7ms. If you need 20ms for a cycle, the delay will be until the next sync again, in total of 33ms.
Use vertical sync in your graphics API instead, which will limit your game to 60 fps if your screen is set to 60 Hz.
Posted 22 October 2012 - 10:45 AM
Posted 23 October 2012 - 02:19 PM
Posted 25 October 2012 - 07:48 AM
Posted 25 October 2012 - 08:22 AM
Posted 25 October 2012 - 02:49 PM
3DModelerMan, if you are targeting android, there are some articles on their site about tricks on how to do common tasks to reduce the drain on the battery.
Posted 26 October 2012 - 01:38 AM
Edited by slicer4ever, 26 October 2012 - 01:39 AM.
Posted 26 October 2012 - 02:19 AM
Posted 26 October 2012 - 02:31 AM
I get the same message from both threads: Don’t use sleep() unless the game is in the background.
nife87 and Erik Rufelt correctly warned against it here just as others had in your thread (by Bacterius for example).
yes, but this wasn't made clear until just a few posts ago, before then, everyone assumed he was working with windows in mind.
You should note that this person is asking for advice on a mobile platform (Android) where battery life is a concern, and in this case “the CPU is a resource so use it” doesn’t have the same weight.
He is also asking about just a main loop, not including rendering, physics, etc.
Basically, you got the correct answer for your situation and he got the correct answer for his. You don’t share the same situation so you should not expect exactly the same answer.
is their an alternative to sleep that doesn't cause the cpu to be used constantly, or should i simply not care that i'm utilizing 100% of the resources?
How much CPU usage should show when an engine is running an empty game loop?
Posted 26 October 2012 - 02:51 AM
While I agree with the sentiment of your post, there are several factual inaccuracies present that need to be addressed:
Here is why the above post is -3.
- Battery life is not your only concern, so just because something plugs into a wall does not mean there is no other possible reason not to want to reduce the CPU load.
- If your PC is burning cycles needlessly it runs hot. This can cause your fans to overwork themselves and eventually shut down, allowing the CPU to overheat, possibly causing permanent damage. Though a main loop in itself is unlikely to cause this.
- If your PC is burning cycles needlessly it costs money. A sleeping PC < a normal-use PC < a dedicated Battlefield 3 PC in terms of daily expenses to your electricity bill.
- There are other applications running besides your game (and its main loop). If your main loop takes 99% of your CPU, other applications starve. You won’t get that ever-so-important Google Talk message notification until hours later when the game shuts down.
- If your target device has a battery, you need to give time back to the operating system as much as you can so that it can conserve that battery.
- Your loop isn’t run when it’s run. It is run when you tell it to run. For iOS this generally means a setting on the display link to trigger at, say, 30 FPS. This conserves battery life, whereas telling it to trigger 60 times per second wastes it.
Edited by Washu, 26 October 2012 - 03:00 AM.
In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.
ScapeCode - Blog | SlimDX