while(mainstate != shutdown)
{
switch(mainstate)
{
case login
{
blah
blah
blah
}
case title
{
blah
blah
blah
}
case ingame
{
switch(gamestate)
{
case gameinit
{
blah
blah
blah
}
case gamerun
{
blah
blah
blah
}
case gameshutdown
{
destroy ingame related stuff
mainstate = title
}
}
}
case mainshutdown
{
destroy everything else
}
}
my game loop (is it okay?)
Author
(allegro/c++) inside the gameinit case i load the map and graphics and whatever else is needed, i have a seperate initialization function used for more general stuff that i didnt bother including in the example
Well IMO the loop should look something like:
So each pass, the input affects the data model, then at the end of the pass you simply update the display, render the frame or what ever the dislay might be.
The loop is part of the "Platform Layer" which, I think, should have no game logic in it at all.
But that's just my two cents.
while( running ) { // 1. Handle Input // This part of course depends greatly on how you are getting your input while( inputLeft ) { handleInput( key ); } // 2. Update Display render();}So each pass, the input affects the data model, then at the end of the pass you simply update the display, render the frame or what ever the dislay might be.
The loop is part of the "Platform Layer" which, I think, should have no game logic in it at all.
But that's just my two cents.
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:
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 ();;
I agree with those guys above me, the main loop shouldn't contain game logic. Mine would look something like:
For maintiaining different game states (what your switch block is doing), I recommend having a state stack and a GameState class that controls how the game is 'played' in that state, so updatePhysicsAndGameEntities() becomes gameEngine.currentState.update().
while(running){ processInput(); updatePhysicsAndGameEntities(); render();}For maintiaining different game states (what your switch block is doing), I recommend having a state stack and a GameState class that controls how the game is 'played' in that state, so updatePhysicsAndGameEntities() becomes gameEngine.currentState.update().
I'm not sure how good this method is but I update my game entities every 30 frames mainly because I don't have physics or AI logic that's dependant on high frame rates. My render loop, however, runs every frame.
Something like this in pseudo-code:
while (!done)
{
if (30 frames done)
{
UpdateGameEntities(); //basically animation - runs at 30 fps
}
Render();
}
Something like this in pseudo-code:
while (!done)
{
if (30 frames done)
{
UpdateGameEntities(); //basically animation - runs at 30 fps
}
Render();
}
Quote:Original post by Specchum
I'm not sure how good this method is but I update my game entities every 30 frames mainly because I don't have physics or AI logic that's dependant on high frame rates.
UpdateGameEntities(); //basically animation - runs at 30 fps
That's quite impressive — your program has to render at 900fps in order for the updates to be done at 30tps.
Quote:Original post by Specchum
I'm not sure how good this method is but I update my game entities every 30 frames mainly because I don't have physics or AI logic that's dependant on high frame rates. My render loop, however, runs every frame.
Something like this in pseudo-code:
while (!done)
{
if (30 frames done)
{
UpdateGameEntities(); //basically animation - runs at 30 fps
}
Render();
}
i think this should be like :
float lasttime;
float curtime;
while (!done)
{
curtime = getcurtime;
gamespeed = curtime-lasttime;
lasttime=curtime;
UpdateGameEntities(entityspeed*gamespeed);
render();
}
speed independent game movement. more is the rendering time more will be the entities movement ans vice versa.
Quote:Original post by ToohrVyk
That's quite impressive — your program has to render at 900fps in order for the updates to be done at 30tps.
Erm.. there goes that logic for a six! Theoretically then. ;)
Quote:Original post by ToohrVyk
That's quite impressive — your program has to render at 900fps in order for the updates to be done at 30tps.
Moreover, why to render the same game state 30 times in a row? The only effect would be to heat up the maschine...
@Specchum: Do you mean to limit the game loop to run at 30fps?
while(!done) { curtime = getcurtime(); timedelta = curtime-recenttime; if(timedelta >= 1/30) { input(); update(); render(); recenttime = curtime; }}This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
