|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Tuesday, 26 June 2001||Author: John Hall and Loki Software|
|Published to: develop_articles/Development Articles||Page: 1/6 - [Printable]|
Linux Gaming APIs: Chapter 3 of PROGRAMMING LINUX GAMES
Today's Linux.com article, derived from Chapter 3 of the book Programming Linux Games by John Hall, takes a look at the various Linux gaming APIs you can use to construct your game. Don't reinvent the wheel, and don't compromise your open source roots, and check out this excerpt from No Starch Press.
|Introduction||Page 1 of 6 >>|
No Starch Press provides the follow excerpt from Programming Linux Games by John Hall and Loki Sofwtare Inc. to the Linux.com community. All rights reserved. Used with permission. Read more about Programming Linux Games Don't miss the Linux.com Live! Event with author John Hall. Hall will be available to answer all your questions on Tuesday June 26 th at 11:00 am PDT. Free T-Shirts!
Chapter 3: Linux Gaming APIsI still remember the first game programming book I ever read. By Dave Roberts, it was entitled PC Game Programming Explorer, and it demonstrated game programming with a game called Alien Alley. This was actually a neat game, especially for one intended as a book example: its graphics were smooth, the artwork was top-notch, and it ran well on my rather underpowered system. It would be easy for me to write such a game today, even in a matter of a few hours. But to a neophyte game programmer, it seemed a towering monolith.
Back in the days of DOS-based gaming, programmers generally wrote games by issuing commands directly to the computer's hardware. There were only a few popular types of sound cards on the market, and many were at least partially compatible with Creative Labs' Sound Blaster. Input devices were trivial to program: accessing the mouse required only a few assembly language instructions (interrupt 33h, for those who remember), reading the joystick's position was a matter of a dozen lines of code, and there were several easy ways to collect keyboard input. Video programming was the hardest part of game development at the time: Although nearly every computer had a VGA-compatible display chip, coaxing fast and smooth graphics out of it took a significant amount of skill (due to some of the brain-dead limitations of the PC architecture). In fact, Alien Alley was mostly video code.
Times have changed, arguably for the better. Very few game programmers actually write register-level video code these days; instead, they rely on pre-written interfaces (such as OpenGL, SDL, and DirectDraw). Direct hardware hacking is fun, but it slows down game development and usually produces un-portable code (with the unfortunate effect that many "old school" games are extremely difficult to port to modern environments). Even if I could find the floppy disk that came with my copy of PC Game Programming Explorer, I doubt that I could port Alien Alley to Linux in any reasonable amount of time, simply because it depends on certain hardware-level features of the original VGA graphics adapter.
DOS programs are given free reign of the entire system; they can freely access memory or hardware ports, and they are effectively allowed to shove the operating system out of the way. Linux programs, on the other hand, are not generally allowed direct access to the system's hardware; they must either use interfaces provided by the Linux kernel or obtain special permissions, requiring the program to be executed under the god-like root account (a potential security risk). The Linux kernel also prevents programs from directly accessing certain areas of the system's memory. In return for these restrictions, Linux is able to prevent applications from interfering with one another, thereby ensuring the system's stability and security.
The bottom line is that we'll probably want to avoid talking directly to the system's multimedia hardware, but instead use one of many existing libraries for the purpose. It saves time and effort, and libraries are usually more fully developed and stable than code written for a particular game.
This chapter tours the variety of game-programming toolkits available under Linux. Most are free and open (indeed, I am wary of any Linux toolkit that isn't these days). If you intend to use these toolkits, familiarize yourself with the terms of the GNU Library General Public License (LGPL): It is possible to legally develop closed-source, commercial software using LGPL libraries under certain conditions; something that has been a frequent source of confusion among developers.
Multimedia programming is a broad field, and so we have divided our tour into several categories. Some packages provide several types of functionality, and they will be mentioned more than once. Finally, some capabilities are provided by the Linux kernel itself, in which case we will simply refer to "the kernel" or "Linux."
|Introduction||Page 1 of 6 >>|