There's a good chance that the next Linux game you play, especially if it's a commercially sold title, was made using Simple DirectMedia Layer.
SDL, for short, is a multimedia library API which provides low-level access to a system's video framebuffer, sound output, and input devices including keyboard, mouse, and joystick. It's used in emulators and MPEG viewers to handle the graphics and sounds of these programs, but SDL has mostly become known as an essential toolkit for Linux game development. The Linux port of Civilization: Call to Power used SDL.
In its most basic capabilities, SDL is similar to Microsoft's DirectX API. The big difference is that, besides being open source, SDL supports multiple operating systems. Other than Linux, SDL is available as BeOS, MacOS, Solaris, FreeBSD, IRIX, and, yes, even Windows 32-bit versions. Additionally, the API has bindings to other languages, a few of which are Perl, PHP, and Python.
Written in C (and also working natively with C++), the latest version, SDL 1.2, is available under the GNU Lesser General Public License version 2 or later.
This alternative to Microsoft's well-known and oft-used DirectX comes courtesy of Sam Lantinga, 27, who presently works as a software engineer for Blizzard Entertainment (the makers of Diablo) in Irvine, California. He first made a name for himself in the games industry as one of the prominent players in the Linux gaming development community. His last job was as a lead programmer for Loki Software, renowned for its quality Linux translations of Windows and Macintosh games. (The last projects that he worked on while at Loki were Tribes 2 and Kohan.) Lantinga got his start in Linux game programming while in college when he ported a Macintosh game called Maelstrom to Linux.
Do you have any projects underway or completed that use SDL? Also, any general thoughts?
The genesis for the SDL library came about while he worked on the Windows port of a Macintosh emulator called Executor. He figured that the code he created for the emulator's graphics, sound, and game controller interfaces could be extracted and used separately across other platforms. "I thought it would be handy to write a library to encapsulate this functionality so that other people could use it," he says.
Lantinga started work on what would become SDL in the summer of 1997 and made the first public release of it, Version 0.3, in October of that year.
Comparing SDL to DirectX is a moot point, as far as Lantinga is concerned. Evoking the proverbial "apples to oranges," he jests that the only similarity between the two is that "they're both fruity."
Seriously though, SDL is a much easier-to-use API that is also available on a much wider range of platforms. "You can't do everything that DirectX can do with SDL," admits Lantinga, "but the API is complete enough that over a dozen commercial titles are using it, and innumerable open-source and non game-related projects use it."
The proof is in the number of notable games which use SDL: Creatures 3 and Docking Station, both from CreatureLabs; BlackHoleSun Software's recent debut, Krilo; and Mountain King Studios' revamped version of the classic game Raptor. Other companies, such as Phantom EFX, use SDL for embedded entertainment and casino games. And all the games recently released by Loki use SDL.
|Krilo, Reel Deal Casino, Tribes 2, and Civilization: Call to Power all use SDL.|
It may come as a surprise to know that, according to Lantinga, programming games on the Linux platform is now comparable in ease to developing under Windows. "I believe that most of the technical hurdles are, for the most part, taken care of," he says. "Loki has proven that commercial quality titles are definitely possible. The remaining issues mostly have to do with system configuration -- making sure people have the right software configuration to run the games."
SDL has figured significantly in helping to make commercial-quality games under Linux easier. As its kernel interfaces and drivers have improved, SDL has provided an easy way for developers to take advantage of a system's multimedia capabilities under Linux or the other operating systems that it supports. It's possible to access multimedia functions under Linux without the help of SDL, but SDL makes the work and the juggling of these functions much easier than it would otherwise be with its simple and powerful API.
"For example, SDL allows you to take advantage of hardware acceleration available on the framebuffer console or with the DGA X server," says Lantinga. "Kohan actually uses a modified version of the DGA library that can provide hardware acceleration even if you are not running as root, but have the framebuffer console configured."
As another example, SDL supports hardware-accelerated YUV surface scaling and display. Where hardware support isn't available, optimized C and Assembly routines take over to gracefully handle the decoding. Also, SDL has the ability to run full screen without requiring root access on the XFree86 servers. It's very tricky to do this on all window managers, Lantinga points out, but the latest version of SDL does this very well.
3D graphics add-on cards figure prominently in present-day PC game development, and SDL addresses the latest forms of these technologies by incorporating OpenGL for its 3D API. Another aspect that's important in game development is online play. Although a feature that it doesn't directly deal with, the sockets API of SDL is a portable network layer, so custom gaming protocols can be built on top of that. There's no network code in SDL proper, but there is a "helper" library, called SDL_net, that does cross-platform networking, though it's technically not associated with the core SDL library.
For a programmer and game designer such as Lantinga, interesting things were learned throughout developing SDL "about API design, 2D graphics, multi-threaded programming, and more than I ever thought I would know about lots of different operating systems," he says.
He started out in this project thinking that SDL would be the be-all, end-all API for game development but realized quickly, though, that "SDL is a great tool, but there are some things that it isn't designed to do, or aren't possible to do portably, such as multi-window support, audio recording, video input, etc. We plan to address most of [these] shortcomings in the SDL version 1.3 API redesign."
The most pressing matter that Lantinga has had to deal with for SDL is video. "Technically, it's just not possible to access the screen pixels directly and use hardware acceleration at the same time," he says. "The video hardware is designed so that it's optimized for hardware-accelerated primitives via the graphics engine, but you have to wait for the graphics pipeline to clear before you touch the video memory. If you don't, in the best case, your drawing is interleaved with the accelerated operations. In the worst case, you lock up your system."
The other challenge he's faced with is creating an API which balances between supporting video access that only happens remotely -- with no control over video refresh (X11) -- and access that is "down to the wire" (DGA and framebuffer console). "I think it can be done," he says, "but providing a simple API for doing it is tricky."
The number of people contributing to the development of SDL varies. On average, Lantinga receives patches from three to a dozen people over the course of a month. There are regular participants -- like Mattias Engdegard and Darrell Walisser, who Lantinga singles out for mention -- and some who contribute every few months, as well as random contributions from people keeping up with the SDL development community.
As for the kind of talents and contributors that the SDL development team can put to use, Lantinga invites "anybody who is interested in writing and testing a multi-platform build system. That's the biggest stumbling block in starting the SDL 1.3 development. Nobody has both the time and experience to set it up and test a new build system."
Where Lantinga wants to take SDL from this point on is extensive. The SDL 1.3 API redesign has a long wish list. A few of the high priorities are including multi-head support, better hardware acceleration, custom blit support, and a redesigned sound API which would incorporate features already available separately in the
Something that's particularly tantalizing: Now that Linux has been ported over to the Sony PlayStation 2, it's possible for SDL to have a hand in affecting game development for the next-generation game consoles -- especially if Linux also gets ported over to Microsoft's Xbox and Nintendo's GameCube. Having SDL available on such platforms will likely enable the making of games outside the proprietary licensing agreements that Sony, Nintendo, and Microsoft impose upon officially licensed game developers.
Lantinga recognizes the above possibility but doesn't think the game-console hardware companies have anything to worry about should SDL cross over to their platforms. "At least in the case of the PlayStation 2, commercial [game development] companies are going to continue to write directly to the hardware to wring every ounce of performance from the console," he says. "I don't know much about the Xbox and GameCube, but to get decent performance out of the PS2, you need to use its vector processing units for fast 3D calculations, and the graphics hardware [of the console] isn't well suited to the OpenGL API."
Still, although many of these "homebrew" games will probably be very simple in design, we could be in for the start of a programming scene that makes new games for current game console technology (as opposed to making games for antiquated consoles) -- spurred on by SDL because of its ease-of-use and platform ubiquity.
Howard Wen is a freelance writer who has contributed frequently to O'Reilly Network and written for Salon.com, Playboy.com, and Wired, among others.
Return to the Linux DevCenter.
Copyright © 2009 O'Reilly Media, Inc.