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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Tech Tip: Really Simple HTTP Server with Python
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide