Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Understand where I'm coming from - I've been taught that a game is implemented something like this (pseudocode):

while (!win_condition)
{
   waitforinput();
   updategraphics();
   //etc..
}
exit();

Is there another way to implement the "game loop" without limiting the game to finite "turns"?

This

while (true) 

business seems to eat a lot of CPU, especially for how simple a game I'm making!

share|improve this question
5  
some reading: gamedev.stackexchange.com/questions/651/… –  Jimmy Jul 20 '12 at 19:18
    
I think it should be getInput instead of waitForInput :) –  Miro Jul 20 '12 at 22:27
1  
What makes you think that 'while(true)' eats a lot of cpu? compared to the rest of your update & rendering code, it's nothing. Are you worried about it being called unnecessarily between screen refreshes and waste the effort? If so, then key the loop off a timer. –  Steve H Jul 21 '12 at 0:47

4 Answers 4

up vote 2 down vote accepted

If your game loop is not throttled to a given framerate it will run as fast as it can. Do a google search for fixed time game loop and you'll find in depth comparisons on how these work.

Basically you measure how long your loop iteration took to complete compared to how much time you have per frame at your given frame rate (e.g. at 25fps you'll have 1/25th of a second to complete your game loop while maintaining your frame rate) and sleep for the remainder of time.

Another approach that can work if your game is event driven and has static graphics between events is to poll for user input every so often and then sleep.

share|improve this answer

That really is the best way. Even with a multi-threaded engine, you want to use task batching, so your main loop will still be "update system A, then system B, etc."

So far as eating up CPU, you definitely want to be conscious of that, especially on mobile gaming (but even for PC gaming due to the rising popularity of mobile PCs).

First, always use sync-to-vblank. That'll keep your game loop from running faster than the display. You can use a custom frame rate controller if vblank syncing is for some reason not usable (or if you are using triple buffering). Basically put a microsecond-accurate sleep (not a busy loop) at the end of your loop after doing the buffer swap in order to keep the game from running faster than you need it to.

You can also replace the part that queries system events (the Win32 message pump, for instance) between blocking and non-blocking when you go into screens that have no animation running when the player isnt doing anything, such as a pause screen or the main menu.

share|improve this answer
    
+1 for sync to vblank! I forgot about this - I did it in C when making games but wasn't sure WHY I did it - our instructor just said to. Nice to know WHY. –  PinkElephantsOnParade Jul 20 '12 at 20:27
    
@PinkElephantsOnParade Then your instructor isn't good instructor. –  Miro Jul 21 '12 at 10:20
    
Hahah fair enough. –  PinkElephantsOnParade Jul 23 '12 at 13:03

There are ways to handle the loop differently but since you said your game was so simple, the standard loop is probably what you want. Other ways would probably make the code more complex than what I'm guessing you are interested in.

Its true that the while loop has some issues, like how it will run at different speeds depending on the CPU, but its kinda the de facto standard.

That and it's not really the while loop that eats a lot the cpu, it's what you do in the loop that makes the most impact. You are always going to want a loop for any graphical game because there is no easier way to constantly check the exit condition of your game and update graphics, physics, input, etc.

share|improve this answer

Dosen't matter. The win_condition will be true most of the time. It is the same of putting 'true' directly. And the 'true' approach saves memory, one less variable.

share|improve this answer
1  
I think you're misunderstanding the question. The OP is talking about win_condition being true most of the time, that's the problem. –  Byte56 Jul 20 '12 at 19:47
    
I realy don't understand. If their waitforinput(); realy stop the program until it get some input the game loop won't continue runing. –  RawArkanis Jul 20 '12 at 20:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.