upFRONT

Welcome to another episode of typical brilliance. Yes, it's time for another round of Stupid Programming Tricks. We've been doing tricks for a while, and we can make some neat stuff, but are we as cool as the guys who wrote arcades such as Ms. PacMan, Arkanoid and Joust? Those were pretty fun video games, even if they were 2-D and took place on stationary backgrounds. The point is, software can be truly fun even if it's simple, and the most elegant game would likely be the simplest. (I imagine you can find Go enthusiasts who would agree.) Now, imagine if thousands of people across the world were playing a video game you wrote—that'd be pretty amazing.

The C language, libraries and GNU/Linux tools make it possible to develop software quickly, and game programming is one of the very best ways to learn how to code. It involves challenges of interface design, graphics and animation, real-time scheduling, collision detection, physics, sound, hardware interfaces (such as keyboard, joystick and mouse), as well as limitless creative scope. Best of all, game programming techniques are applicable to any kind of programming, from audio and video applications to user interfaces and indeed any program from “Hello World!” on up.

Programing an entire game is a mildly difficult project that could take a few days, but we'll look at one of the most basic elements, something applicable to any application involving graphics. We've already discussed how to initiate console graphics, how to scroll text across a screen and how to play music and sound. Now, we'll take a look at something simple but important: how to move an object smoothly over a background without damaging the background.

For our purposes, we'll start with the usual SVGAlib (you know, runs-as-root-not-very-safe SVGAlib), and initialize two screens: our virtual screen and our physical screen. The standard procedure, as you may remember from previous episodes, is to do all our drawing to the virtual screen (because it's much faster and flicker-free), then copy the virtual screen to the physical screen and hold it still for 1/60th of a second (the duration of a vertical refresh, which could even be 1/85th of a second on really fast equipment). For our background, we'll generate something cool by drawing a few lines and applying some sine equations to the pallette. As for the shape we intend to slide over the background, we'll use some equations to make a very funky square. Obviously, it's a small step to go from this situation to loading a custom-drawn background and an animated character, but we'll stick with our simple approach, largely because algorithms that generate graphics are inherently cool.

If you draw a background and then move your graphic across the screen, you'll leave a trail of pixels and ruin the background, which often happens periodically on slow computers running X. (You may remember the grey smears caused by moving a window, especially in Netscape and advanced window managers.) One solution is to redraw the entire background, then stamp your graphic in its new location. The problem with this approach is it severely wastes processor resources (you'll be redrawing the background at least 60 times every second), which makes for slow programs. Personally, I favor fast code and hack-job optimizations over structurally organized, procedural code; for example, loops instead of recursive algorithms. Redrawing the background often makes sense, if you're making changes to the entire background or if you do not have hardware scrolling capabilities. Suppose you have a 320x200x256 background (320 pixels wide, 200 pixels tall, with 256 8-bit colors), and you want to move only a 16x16 graphic across it. Think Ms. PacMan. Why not just draw the heroine and the ghosts? Why redraw the maze all the time, if it doesn't change? How much is actually moving?

The procedure we'll use is known as the cookie-cutter technique. It involves making a backup copy of the area onto which you want to stamp your graphic (on an Amiga, we'd call it “blitting” rather than “stamping”). Essentially, you make a backup copy of the target area, stamp your graphic over that area on the screen, hold it for a vertical refresh (so that the image is present long enough for the eye to register it), then replace the stamped area with the backup (cookie-cut) you made, stamping the background over your old image, and start again. As long as your graphic uses transparent or masked bits (instead of stamping solid black), you'll see your graphic sitting nicely on top of the background. It's the same situation as laying a graphic on the background of a web page, only here it's moving.

In our actual program, you'll notice we're using a physical screen and a virtual screen, when we could get by if we used only a physical screen (after all, copying a virtual screen to a physical screen is a more processor-intensive procedure than copying 16x16 pixels of background to a backup buffer, blitting a 16x16 image, and replacing the 16x16 background segment). The point is that drawing to a virtual screen is very fast, and if you ever want to do more than a single moving box, you'll be very happy you're already using the virtual screen. Extensibility is a good idea, especially when you leave things open for your own imagination.

The routine for moving the box will be simple. We'll use a sine for the x coordinate and a sine for the y coordinate (it'll look very smooth). We need to avoid accidentally drawing parts of the graphic out of bounds (which can lead to a segmentation fault), so the equations won't look exactly like 160*sin(x)+160 or 100*sin(x)+100, but they'll be fairly close. Sine equations are very useful, and chips these days are very fast at trig so you don't have to worry about optimizing, for example, by building a table of already-calculated sine values. For fun, we could also cycle the colors so that the image would look groovy, but you can try to implement this yourself, if your computer is fast enough. Here we go, and remember, this time we'll need the math library, so compile with

gcc -Wall -O2 joyousbox.c -lvgagl -lvga -lm -o\
  joyousbox

(recent gcc/egcs versions will automatically link the math library, but to be sure, we like to include it). See Listing.

—Jason Kroll