Basics of Game Structuring

Member
Posts: 185
Joined: 2005.02
Post: #1
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:
Code:
--#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.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
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/Anim...tion.xhtml
Quote this message in a reply
Member
Posts: 260
Joined: 2005.05
Post: #3
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.
Quote this message in a reply
Post Reply