The BallBouncer class is responsible for moving these balls: it needs to periodically consider how much time has passed since the last update, divide the X and Y components of the motion vector by that time to get the distance the ball has travelled in each dimension, and update the ball's position. If a ball hits a wall, its motion vector needs to be adjusted accordingly -- for this article, we use an extremely simplistic reversal of X or Y velocity on an impact. For a consideration of more realistic forces (such as acceleration, friction, spin, etc.), please see David M. Bourg's Physics for Game Developers.

In the old days, we would typically have a single loop responsible for handling user input, game logic (such as calculating object positions, which we are interested in here), and repainting the screen as often as possible. But this approach has apparently fallen out of favor somewhat. Game designer Mike Stemmle, who co-designed and co-directed Escape from Monkey Island and the recently (and in my opinion, inexplicably) cancelled Sam and Max: Freelance Police, explains it this way: "Given the power of most machines these days, we can afford to be more anal about separating game logic from graphics code." Stemmle explains that the current practice is to not just separate the code for these functions, but to have them in different threads, to completely separate the tasks.

In this spirit of this arrangement, BallBouncer does its updates on the AWT event-dispatch thread, by way of javax.swing.Timer callbacks. This also ensures that changes made via the user interface will be thread-safe.

But what about the painting? For that, JOGL provides a class called Animator that has its own thread to repeatedly call the display() method for a GLDisplayable, such as our GLCanvas, as often as the CPU will allow. If that sounds like overkill, check this JOGL forum post for FPSAnimator, which optionally limits the display() callbacks to a specified rate.

Creating and starting the Animator is simple: construct it with a GLDisplayable argument, then start() it. In our example, the code looks like this:

Animator animator =
    new Animator(bbf.ballBouncer.getCanvas());
animator.start();

One note on the care and feeding of the Animator: the GLDisplayable apparently needs to be on-screen and fully initialized before handing it to an Animator. I even found an occasional not-quite-initialized exception that I worked around by stalling for a second between the end of my GUI setup and starting the Animator.

At any rate, having established how the logical animation of the balls' positions and the Animator-driven painting works, feel free to exercise it by setting the number of balls to some value greater than zero. The bouncing balls are shown in Figure 3.

Figure 3. BallBouncer animation

If you think that the use of two threads, one for motion logic and another for painting, is a potential thread-safety risk ... you're absolutely right. It's possible to change the number of balls to paint while the display() method is counting through the list, resulting in an ArrayIndexOutOfBounds exception, although the painting is so fast you'll need thousands or tens of thousands of balls to get into this state. Fixing this is left as an intellectual exercise for the reader. There are a few interesting options, and choosing one may depend on your development philosophy and priorities:

• synchronize access to the ArrayList so that only one thread can read or write it at a time. Straightforward, but thread synchronization is expensive in some JVMs.

• Set up "gate" logic so that display() doesn't try to draw unless the ball positions have updated. This way, changes in the update logic can't be concurrent with display(). This is a nice optimization, too.

By the way, the last article didn't note anything about drawing curved surfaces, so how are the balls drawn? Well, they're not actually curved: it's fast and cheap to just use regular polygons, so these "balls" are actually 36-sided regular polygons, with each vertex on a circle that fits neatly within the Rectangle that describes the ball's position and size. Given a radius of half the Rectangle's width and a center at (cx, cy), the "circle" is drawn by:

gl.glBegin (GL.GL_POLYGON);       
for (double theta = 0; theta < TWO_PI; theta += ARC_SEGMENT) {
    int x = (int) (cx + (Math.sin(theta) * radius));
    int y = (int) (cy + (Math.cos(theta) * radius));
    gl.glVertex2i(x,y);
}
gl.glEnd();

Since we're already scaling down coordinates (the rectangles are 150 by 150), the angularity disappears as a side effect of the scaling.

Transformation

One valid complaint about the use of circles is that they're terribly easy: they don't point in a specific direction and it's easy to draw them larger or smaller by just changing the radius. An arbitrary shape would be a lot harder.

Fortunately, our drawing in OpenGL can benefit by using affine transformations. If you've worked with Java 2D Graphics or similar graphics APIs (like the QuickDraw package exposed by Apple's QuickTime Java), then you may have encountered these before. They are algorithms for transforming points from one coordinate space into another, often expressed as matrix multiplication. They have the nice feature that they can be combined. But what do they do? Here are three that are interesting in 2D:

• Translation: Move the coordinate system so that drawing occurs in a different location.
• Rotation: Rotate the coordinate system (specifically, rotate the X/Y plane about the Z axis).
• Scaling: Recalibrate the coordinate system so that the units represent a different amount of distance.

To exercise the affine transforms, BallBouncer can replace the balls with arrows that point in the direction in which the ball is moving. We'll use this to exercise the rotation transformation. Since the center of the rotation is the origin of the coordinate system, we'll use translation to move the arrow to its proper position. And just to show off, we'll draw the arrow at an arbitrary size, 100 by 100, which doesn't match the size of the balls' rectangles; the scaling transformation will fix this.

Figure 4 shows how the three transforms will achieve the desired effect.

Figure 4. The effect of three affine transformations

Here is the code for drawBallAsArrow() that exploits the affine transformations:

Rectangle rect = ball.getRect();
gl.glMatrixMode (GL.GL_MODELVIEW);
gl.glLoadIdentity(); 
gl.glTranslated (rect.x+50, rect.y+50, 0);
gl.glScaled (rect.width/100d, rect.height/100d, 0);
gl.glRotated (ball.getAngle(), 0, 0, 1);
gl.glBegin (GL.GL_POLYGON);
gl.glVertex2i (50, 0);
gl.glVertex2i (-50, 50);
gl.glVertex2i (0, 0);
gl.glVertex2i (-50, -50);
gl.glEnd();

The affine transform calls are:

• glLoadIdentity()
  Resets the affine transforms to the "identity" matrix, in which every transformation returns the original point. This clears out any previous transforms we sent to OpenGL. Remember from above that this is the last unexplained method call in our reshape() and/or resetWorldWindow() implementations? Now you know why we needed it: we needed to reset our drawing to work with the original, non-transformed coordinates.

• glTranslated()
  Adjusts the coordinate system to move the arrow to the location of the ball, plus 50 pixels right and up, since our drawing code uses an arrow whose rectangle's lower left corner is at (-50, -50). Notice the trailing 0 argument: this is our Z axis rotation, and we don't care about the Z axis because this is 2D.

• glScaled()
  Scales our 100 by 100 arrow up to a size appropriate to the ball's Rectangle. Again, the last argument refers to the unused third dimension.

• glRotated()
  Rotates our coordinate system by the number of degrees calculated by the ball the last time we set its movement. The (0,0,1) arguments define the Z axis, which is what we rotate about.

Finally, having defined this set of transformations, drawing our arrow requires only that we enter polygon-drawing mode and specify our four points.

To show this off, click the "Draw as arrows" checkbox. Figure 5 shows the full effect of our OpenGL bag of tricks: arrows to exhibit affine transformations, a zoom to display the effect of setting the world window's size, and the animation provided by the Animator class.

Figure 5. BallBouncerFrame in "Draw as arrows" mode

Game on!

Thinking back to the great video games of the 80s discussed in the introduction, you may already see plenty of similarities. These games were all about straight-line motion: missiles, bombs, flying ships, rolling asteroids, etc., all of which can be modeled and animated with the simple techniques shown here.

But what about interaction? How do we know when two objects, like a missile and a robot, collide? This is one of the reasons I used AWT Rectangles to represent the moving objects: the method Rectangle.intersects(Rectangle r) makes checking for collisions trivial. It would be simple to extend the method that updates the ball positions to also do collision checks and take an appropriate action (bounce the balls, destroy one, etc.). Throw in player control of one or more objects, and you've got the beginnings of a high-performance 2D game.

Chris Adamson is the former editor of java.net.