Quote:Original post by Spoonbender
Try quitting your game and call up the task manager. The Idle process usually uses 99% of the CPU. That means the CPU is doing nothing 99% of the time. So why shouldn't your game take the CPU time it's offered? If you make your game call Sleep, and give away the CPU, then that will just go to the Idle process, which does nothing with it. How is that an improvement?
(And yes, I know I simplified all the above quite a bit)

Nice explanation overall (rating++), although I would point out that your simplification makes it sound like there is no point to calling Sleep() in a game. It is not necessary, certainly, for all the reasons you listed, but if one has the time, it is nice to add a bit of code which throws in some real short Sleep() calls whenever the game is running faster than say, 60 FPS. This increases the responsiveness of the rest of the system a bit, since the OS seems to have an easier time freeing CPU cycles from the idle process when other apps need it than from a game, and it also makes it so that your game won't necessarily cook the user's processor; the idle process is a bit different than a busy loop because it somehow actually lets the processor idle, and thus use less power and generate less heat. And it doesn't decrease responsiveness if you do like I said and only use Sleep() when the game is already running so fast the user can't tell the difference. Definitely not necessary, but I like to do it if I have time, since it always pisses me off when game designers assume that no one will want to switch away from their game but still leave it running.

Quote:Original post by mumpo
Nice explanation overall (rating++), although I would point out that your simplification makes it sound like there is no point to calling Sleep() in a game.

Fair enough, I figured running an entire CS course was probably overkill. :)

But yeah, Sleep has its place, definitely. (After all, pretty much all the other running processes use it all the time).
Just be sure to understand what it does. It makes you give up CPU time that had otherwise been allocated to your game. Of course, if you don't need the CPU time (if you want to cap your framerate at, say, 60 FPS, or if you're making something like Windows' Solitaire, you don't need to constantly refresh the screen), then it makes sense to call Sleep, so other programs can benefit from the CPU time you don't need.
Just keep in mind, *only* do it when your game actually needs to wait before doing anything.

Quote:
Definitely not necessary, but I like to do it if I have time, since it always pisses me off when game designers assume that no one will want to switch away from their game but still leave it running.

In that situation I'd prefer to just enable vsync. Then your game only refreshes as many times per second as the monitor can display, and you don't need to use Sleep, the driver takes card of that much more elegantly.
Of course, when the game is inactive (minimized or in the background), you should definitely pause it and call Sleep() or whatever else you've got. :)

Quote:Original post by Spoonbender

Quote:Original post by mumpo
Definitely not necessary, but I like to do it if I have time, since it always pisses me off when game designers assume that no one will want to switch away from their game but still leave it running.

In that situation I'd prefer to just enable vsync. Then your game only refreshes as many times per second as the monitor can display, and you don't need to use Sleep, the driver takes card of that much more elegantly.
Of course, when the game is inactive (minimized or in the background), you should definitely pause it and call Sleep() or whatever else you've got. :)

That seems like a good way of doing it, and I generally do enable vsync, except that my game engine is designed to be able to run windowed or fullscreen, and not know the difference. Vsync doesn't seem to do anything in windowed mode, but Sleep() does.