Before I start with anything, we have to think about simple animation. In fact, animation is just simply a series of static images, with each image slightly displaced from the last.

So what does that mean?

For example, if I’m going to draw animate a ball falling from mid-air, I would first start with an image of the ball in mid-air, precisely as it would look the moment it began to fall. The next frame, or image, would be exactly that, but with the ball a little bit lower down. I would then continue to draw sequential images of the ball, with each image showing it a little bit further than the last. This is how every moving image you see works (well, just about). A series of images is drawn in front of you, quick enough that you can’t tell.

So the next question is, what’s quick enough? It turns out, this isn’t such a simple question. In fact, the answer is different for different animals! But for humans, it turns out, about 30fps, or 30 frames-per-second, is what it takes to fool us. The movies you see in the theatre are (at-the-moment anyways) displayed at 24fps, but most computer screens require 60fps to prevent you from seeing the flicker (some, like myself, need an 85Hz (fps) refresh rate, others up to 120!). The reasons for these differences has a lot to do with the way the image is drawn and the way your eye views things. It’s a pretty involved topic, but if you guys would like me to go into it more, let me know in the comments.

A Simple Animation Loop

Taking what we just learned, let’s think about how to draw a box moving across the screen. Let’s pretend we have a function that draws a box centered at a point we specify on the screen (in 2-D Space). It’s C function prototype would look something like this:

void drawbox(int x, int y);

So if we were going to draw a box that just infinitely moved to the right (or at least until it was off screen). We might decide to create a loop that drew it a little bit further each time. That might look something like this:

#define TRUE 1

int x=0;

while(TRUE) {

drawbox(0+x, 0);

x++;

}

This little snippet of code, runs an infinite loop and draws a box at a point 0+x, 0 and then increments x. Let’s look a little further. First it draws a box at point(0,0) since x is 0 on first count. Then x is incremented and the loop goes on again. Next, it draws a box at (1,0) and increments x. And so on. Congratulations, you just made your first animation loop!

Marching Onward

In the beginning, video games were hand-coded in assembly directly to a particular hardware. This had a lot of benefits, primarily speed, which was very important when hardware was relatively expensive. But as computers progressed and the market expanded, it became necessary to program for a multitude of different hardwares. And this is when a nasty problem reared it’s head. You see, when you decide to have the computer draw something on the screen, it doesn’t just do it instantaneously. The computer has to go and draw each individual pixel on the screen (also a topic for another discussion).

This

takes

time.

Moreover, the time it takes on your brand-spanking new ultra-super processor is not the same time it takes your friend down the street who isn’t as enthusiastic as you are. This is a problem, because if you set up all your animations expecting the processor to draw 30 frames per second on your machine. It’s going to run at less than that on your friends machine. (In fact, there’s some math that shows it will be a fraction/multiple of their refresh rate). Great, so your fast-action shoot-em-up just got stuck in the mud.

What’s a game programmer to do?

There’s a really simple answer to all of this–use our friend (archenemy) time. You see, rather than making your animation speed depend on the animation loop (which depends on your processor speed), have the your animation be a fixed function of time.

Take another look at our first example. The movement speed of the box can really be expressed as 1 unit in the x direction per loop iteration. Really what we want is for the box to move some number of units in the x direction per second (our hour if you like). To do this we need to express our box movement as a function of time and then know how long its been since the computer last drew the box. Essentially, we want our animation loop to look like this.

#define TRUE 1

int speed = 1; //1 unit per second

int x = 0;

startTime = 0;

elapsedTime = 0;

while(TRUE) {

startTime = getTime();

x += speed * elapsedTime;

drawbox(0+x, 0)

elapsedTime = getTime() – startTime;

}

As you can see, this simple example becomes a lot more complicated once we add timing to the mix. First, we defined a universal speed for our box. We still kept the x value, as this represents the boxes point in space, not it’s speed. Then we created variables for keep track when we started our animation loop and how long we were in it. We’re also assuming we have a function that gives us the time, called getTime() here, and that it returns us the current time in seconds.

First we enter our loop and fetch our start time from the getTime() function. Next we set our x position based on how long it’s been since our last loop. We multiply our elapsedTime by the speed of our box and add that distance to our x-position. Then, we draw our box at it’s new position. Finally, we figure out how long it took us to draw that box by setting our elapsed time equal to the current time minus the time we started drawing the box. Now, no matter the computer, our box will move along the screen at the same speed. Note, this does not mean the animation is fluid! If your friend’s computer is really slow (and I mean really if it can’t draw a box) it may only get to draw a box once every 5 seconds. By then, our box may already be off the screen!

So I hope that’s enough for you to digest for a while. Stay tuned for my next post on some of the basic mechanics of GLUT and OpenGL. Until then, it might be useful to brush up on your C programming on the interwebs!

If you ever wanted to program your own video game, this is a good place to start. I remember when I started learning programming it was surprisingly difficult to find out how to make an honest and simple game. In fact, after reading most programming books, the only type of game you could make would be a Zork clone.

You are in a dank cave and you can see nothing, but you hear a walrus in the distance.

What do you do?

1. Look for the walrus.
2. Watch The Big Lebowski
3. Decide that the walrus is Paul.

This is not to knock Zork in any way! Zork is a clever, well written, and extremely well thought out game (even if my pseudo-quote isn’t). But in a world where we’re spoiled by moving objects, you want to know how to move and interact with something on screen. The problem is it takes a lot of different knowledge sets to get the job done. But in this post, you’ll get started learning how to make your very own Pong clone.

A Few Notes..

First, a few notes about setting up. I’m writing this tutorial from the Mac OS X perspective. However, everything we are about to code is, essentially, cross-platform. This is because, it is written using plaing old C, OpenGL, and GLUT. All of these things are themselves cross-platform, and therefore, can be compiled anywhere you have a C compiler (OpenGL and GLUT are just C libraries).

Setting up your environment

Mac OS X

For some reason, this always seems to be the hardest part whenever learning something new in programming. Fortunately, I found a great blog post that makes setting up XCode for compiling an app using OpenGL and GLUT very easy. Read all about setting up your XCode.

Windows

The process in Windows is actually a bit easier (gasp!) than in Mac OS X and there’s plenty of resources available on Google for getting setup. Here’s one in particular.

Linux

Here’s something unusual, you guys get a video.

Congratulations, the hardest part is done! In my next blog post. We’ll start to get knee deep in game programming concepts.

Update!

Part II is Up!