Basics of Game Structuring

[ferum]

Ok, I know we have had these sort of discusions before but I'm talking really basic. Right now I have been making really simple openGL demos (ie press a button and the cube rotates) using GLUT. so my basic structure is:

--#include statements--

display()
{
glClear(), glLoadIdentity(), glPushMatrix() etc. display stuff
}

reshape (int width, int height)
{
glViewport(), glMatrixMode(), etc.
}

idle ()
{
glutPostRedisplay();
}

int main (int argc, char** argv)
{
glutInit(), glutInitDisplayMode(), glutInitWindowSize(), glutCreateWindow()calls

glutDisplayFunc(display);
glutReshapeFunc(reshape);
glutIdleFunc(idle);

glutMainLoop();
return EXIT_SUCCESS;
}


Also any variable I need to keep track of the location things and such I have been making global variables since the program is constantly exiting the display() function and re-entering it.

I hear people talking about a main loop. Where do I put such a loop?
How does this glutMainLoop() thing work?

I'm really sorry if this is hard to understand. I'm having a hard time articulating right now, I'll probably go back later and edit it.

[OneSadCookie]

glutMainLoop() is your main loop (duh?). It calls back the registered callback functions (in your case "display", "reshape" and "idle") at the appropriate moments.

I don't really know what you want to know about structure, though...

Mine usually record user input in global variables as it arrives, then from the display callback, run the physics, then draw the current state of the scene. You can find a tutorial on how to run a physics loop here: http://sacredsoftware.net/tutorials/Animation/TimeBasedAnimation.xhtml

[Ingemar]

What I see above is the structure of a simple GLUT program. I think you should separate your game thinking from that. Even if your game loop is really called from a GLUT timer function, I would make that an entity of its own.

The typical structure of a game, or any Mac program is 1) initializations and 2) main loop. The main loops takes care of user input, updates game state (positions etc) from input, physics etc, and the display function draws what it should from the game state. But I would think more about representations of the game data. Once that is in hand, the game code structure is a smaller problem.