views:

1935

answers:

4

I'm having trouble creating a solid game engine for my OpenGL application. It's a game which consists of several sprites with a lot of action.

I created objects which are basically all of my sprites. Another object called "gameEngine" loops through a set of calculations every something of a second (a timer), resulting in new game variables. After that, the sprite objects now know their drawing data.

The problem is, that after collecting all of my drawing data, the drawing should take place at exactly the right moment in time, resulting in a steady animation. Depending on the complexity of the current scene, the game calculations take an undetermined amount of time. So, the actual drawing takes place at different moments in time. How would I prevent that from happening?

To clarify, my approach goes something like:

// Every something of a second I call tick
-(void)tick
{
  drawingData = gameEngine();
  draw(drawingData); 
}

There must be a best practice for building game engines like this I'm not aware of?

A: 
Reed Copsey
+1  A: 

This really isn't about OpenGL; it's more to do with the operating system or system APIs you're using (i.e. Carbon/Cocoa/Win32). But the really, really simple case is this (pseudocode):

checkTime = currentTime
while not exitCondition
    if currentTime - checkTime >= 50 milliseconds
        checkTime = checkTime + 50 milliseconds
        updateScene
    else drawScene

You are drawing as often as you can, but only doing the updates every 50 milliseconds (i.e. 20 times per second). There are obviously a lot of other things to think about, especially in terms of what you do when you fall behind (skipping frames).

The best place to get into OpenGL stuff is Nehe's lessons:

http://nehe.gamedev.net/lesson.asp?index=01

They're getting a little dated, but the sample code at the bottom of each lesson is a great place to start, and it's available in many languages and for many operating systems.

DNS
+1  A: 

The best solution would be a multi threaded application - one thread calculating the drawing data into a buffer and one rendering the data.

If you are looking for a realy simple solution, just invert the order of calculation and rendering.

void Initialize()
{    
   DrawingData = GameEngine();
}

void Tick()
{
   Draw(DrawingData);
   DrawingData = GameEngine();
}

You calculate the first drawing data on application start up and when the timer fires you just draw it. After that you have all the time up to the next timer event to calculate the drawing data again.

But in general it may be a better solution to render at a variable frame rate - you avoid the problems if the machine is to slow for your desired frame rate and you provide high frame rates on fast machines.

void Main()
{
   StartTime = Now();

   while (!ExitRequested)
   {     
      DrawingData = GameEngine(Now() - StartTime);
      Draw(DrawingData);
   }
}

You render frames as fast as possible - not with a fixed interval between each frame but instead with the real time the application is running. That means do not advance your objects by 20 milliseconds every frame, just move them to the position the current running time says.

Daniel Brückner
Actually, using a fixed step game loop is generally the preferred option unless you program something really simple.
Andreas Magnusson
+2  A: 

Game loops come in many varieties but the better ones separate the animation from the drawing or in more classic terminology model and view. Basically you want to construct a model of your game where you can establish the passing of time and update the model (physics framerate) and then independently render a snapshot of the model at consecutive moments in time (rendering framerate).

Here are a couple of articles which give a more detailed explanation of some of the variations on game loops and their pros and cons. There is source code too. I hope it helps.

Fix Your Timestep! and deWiTTERS Game Loop Article

Arnold Spence
Serious +1 for "Fix Your Timestep!". This is a must read for anyone that wants to really know the best way to design your game loop. It may take a couple of reads to understand it in the way it is presented but it's really very simple.
Mike Weller