Quote:Original post by ToohrVyk
It's one way to do it, and it is acceptable for very small projects where you only have a small number of possible game states, and (very important) the game states do not need to store internal data exclusively.

For any non-trivial project (i.e. anything past Pong, Tetris or Breakout), it's better to drop the switch altogether, and use a stack of polymorphic game state objects instead, as these can encapsulate game behaviour much better.

My typical game loop looks like this:

let loop () =  (* Prepare a new frame *)  let scheduler = schedulers # top in  let time = timer # now in  (* Read input *)  input # poll time;  (* Update state *)  while scheduler # next < time do     scheduler # pop # execute time   done;  (* Render scene *)  renderer # frame time;  (* Repeat *)  loop ();;

Anyone have any good beginner articles/tutorials on this subject? I'm interested in what Toohr said but having a hard time grasping the concept because of the language he uses.

It's quite simple really - as with most good object-oriented designs, you should use subclasses where practical instead of switch statements. The classes have methods such as Update() or Render() which you call every frame, and you just swap in the appropriate class (eg. SplashScreen, Game, Menu, Paused) when you change states. Once you're comfortable with that, it's a short step towards having a hierarchical state system where you keep a stack of states, so that you can push a Paused state onto the stack without losing the current GamePlay state.

Quote:Original post by Kylotan
It's quite simple really - as with most good object-oriented designs, you should use subclasses where practical instead of switch statements. The classes have methods such as Update() or Render() which you call every frame, and you just swap in the appropriate class (eg. SplashScreen, Game, Menu, Paused) when you change states. Once you're comfortable with that, it's a short step towards having a hierarchical state system where you keep a stack of states, so that you can push a Paused state onto the stack without losing the current GamePlay state.

could you put some sample code of "swaping" the appropricate class.. would that just be another switch within update or render? or is there another methodto hold these constructs?

Quote:Original post by Ultimape
could you put some sample code of "swaping" the appropricate class.. would that just be another switch within update or render? or is there another methodto hold these constructs?

Within your general game logic somewhere:

if (timeToMoveToNextState)   currentState = NextState()

That's all. Each frame, you call your update/render/input functions on currentState. You change the object that the currentState variable refers to when you wish to change state. Just create a new one of the appropriate type and assign it.

Quote:Original post by Specchum
what I was thinking was that my update should cap at 30fps but rendering should run as fast as possible.

haegarr, basically my loop looks like yours except that the render() is outside the if statement.

IMHO my loop measures the elapsed time, and decides to update and render if 1/30 second has gone. Otherwise it does nothing. Assuming that the update/render stuff durates less than 1/30 seconds, say 1/50 seconds, then my loop yields in 30 fps in both update and rendering. If 1/20 seconds are consumed instead, then it runs at 1/20 seconds.

Your loop as I (and obviously ToohrVyk) understand it, counts frames and updates if the counter has reached 30. Assuming that the update time is 1/100 seconds and the render time also (yielding in 1/50 seconds total like in the example above) then your loop renders 30 frames at a rate of 100 fps. That durates obviously 0.3 seconds. Now an update is done. So, in this example updates are done only approx. 3 times a second (what is definitely too less). To reach an update rate of 30 per second your rendering must be (as ToohrVyk has stated) as fast as 1.1 ms or 900 fps!

So our loops differ in that
(1) my loop does not waste time to render the same state 30 times a row but only once (nevertheless its "active waiting" can be made more effective),
(2) my loop restricts the update/render cycle to an upper limit of 30 fps, and
(3) my loop allows reasonable update rates even if the render time goes halfway into the cellar.

IMHO your loop _is_ capable of performing as you desire, but under unrealistic circumstances only. Please correct me if I'm wrong.

this would be my input for the game loop:

// 1 - class factory invokation, create objects and stuff

while( gameActive ) {
// 2 - Handle the input (keyboard, joystick etc..)
// 3 - have a on keyDown and keyUp conditions so only within that
// period that events happen
while( onKeyDown ) {
handleInput( key );
}
while( onKeyUp ) {
handleInput( key );
}

// 4 - Update objects, render etc..
render();

// 5 - Need to check if game still active
}

what do u guys think?