Main game loop.

Pretty much.

In practice you need to do things to regulate the speed, and most graphics output systems these days involve some kind of double buffering; buffers need to be swapped at the end of the frame and reinitialised at the beginning.

But apart from that, yes that''s what you do.

Mark

mr_schmoe,

No, the main loop doesn''t need to be very complicated, but it does need to be more complicated than what you''ve got. Basically, you can delegate everything to other functions and you''ve got a nice clean looking main loop, but often there are other considerations than just the players moving and being drawn. Network code, AI [is that in your enemy.update psuedocode?], message handling and other graphics stuff etc.

For example, Quake 2''s [what I''m working with at the moment] ''main'' loop is only 40 lines long, and that just handles messages and passes the current time along to another function, QCommon_Frame(). But then QCommon_Frame does a bunch of other stuff, and then delegates updating of both the server [SV_Frame()] and client [CL_Frame()] subsystems after doing about 80 lines of stuff. Each of these then calls 10 or 20 more functions, which in turn call other functions.

So basically, the answer to your question (to my knowledge) is that the main loop can be really simple, it''s just that when you unroll it, you still have to get everything done each frame. I could make my main loop while(!done){ doFrame() } .

In my opinion, a good programmer makes their main loop simple and easy to understand, while a bad programmer makes their loop confusing because they do not share the right variables to the right places.

I hope that helps

//end rant

CJM

That does makes a lot of sense. Thanks.

Here is my main game loop :

if( !Initiate() )
   Quit(0); // A homemade function that quits out of the API


while( true )
{

   ProcessInput(); // This is obvious


   Logic(); // In here you have your if statements and stuff


   Render(); // You draw all of the game objects here   


   Update(); // This is where you change variable content related to the game objects


}

DeInit();

n a game loop does it matter if you update the game scene before or after rendering?

It shouldn''t make a huge amount of difference, but if you''re waiting for the video card to return from a draw operation (such as if you had v-sync enabled), then it might make sense to do your update code then.

Mine basically looks like this:

int CGame::Run()
{
    while(true) 
    {
      // OS-dependent stuff (e.g. windows message handling)

      int iResult;
      iResult = HandleInput();
      if(iResult > 0)
         return iResult;
      iResult = Update();
      if(iResult > 0)
         return iResult;
      iResult = Render();  
      if(iResult > 0)
         return iResult;
    }
    return 0;
}

what i did was simply create a window class that had a few virtual functions, these functions get called within the windows code, but to actually use them you need to derived the windows class and then fill in the functions...

class CGame : public CWindow
{
public:
  ...
       bool InitSystems(void);
       bool LoadScene(void);//really only used to load gui stuff and splash screens.

       bool DrawScene(void);
       bool UpdateScene(void);
       void FreeScene(void);
};

Within these functions you setup the window, set flags like using opengl, and you can call say ShutDown() which preps everything for shutting down. It works pretty nicely.

The last thing you do is simply make the windows main function...


int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrev, LPSTR cmd, int cmdShow)
{
CGame application;

g_log = CLog::GetInstance();
g_log->OpenLog("log.html");

if(!application.RenderWindow("Some title",hInst,window_width,
window_height,color_depth,fullscreen))
{
return 0;
}
return (application.RunApp());
}
[/source]

EDIT: actually update(float time)... the windows main loop function handles the time using my timer class.

~Jay



[edited by - no one on May 30, 2004 11:12:08 PM]

[edited by - no one on May 30, 2004 11:12:59 PM]

Hehe. Read Code on the Cob.

[edited by - vnillabrent on May 30, 2004 12:58:05 AM]