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.
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
|Trying to Tame the Tablet||May 08, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Readers' Choice Awards
- Android is Linux -- why no better inter-operation
2 hours 13 min ago
- Connecting Android device to desktop Linux via USB
2 hours 41 min ago
- Find new cell phone and tablet pc
3 hours 39 min ago
5 hours 8 min ago
- Automatically updating Guest Additions
6 hours 17 min ago
- I like your topic on android
7 hours 3 min ago
- Reply to comment | Linux Journal
7 hours 24 min ago
- This is the easiest tutorial
13 hours 39 min ago
- Ahh, the Koolaid.
19 hours 17 min ago
- git-annex assistant
1 day 1 hour ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?