Why Use SDL?

Portable, easy (and yet) powerful.... - Gaëtan de Menten

As I write this is August of 2002 I've been using SDL (Simple DirectMedia Layer) for nearly a year. Before choosing SDL I spent several years in my spare time looking at different game development libraries and trying them out. I was looking for a library that had a reasonable license. A library that lets me write code without having to worry about a lot of legalities and that doesn't force me to pay a small fortune in royalties if I come up with something that has commercial value. I also wanted a library that let me write code for a wide range of devices and operating systems. With the growth of hand held computers and wireless phones with graphic displays it seems unreasonable to tie development to a single OS or architecture. After looking for a long time (I admit I was looking more as a hobby than as a business) I came up with a list of three systems that looked interesting.

The first of these was Java. I'm very fond of Java as both a language and a system. It has everything you need to write great games. But, it isn't available everywhere and I realized that expecting people to download and install 20 (or more) megabytes of code and install it on their computers before they could play my game would seriously limit on line distribution of any games I wrote. I also looked very closely at the new portable multimedia system from Amiga. But, the more I worked with it the less I liked it. After a quick look at several free game development libraries I decided to take a detailed look at SDL. What I found out about SDL came as a surprise to me. Unlike most free game libraries you find on the web, SDL was designed and written by a group of experienced, highly professional, game programmers. Not to knock the authors of other competing libraries, SDL just happens to be supported by a huge collection of good programmers. SDL was written by game programmers for game programmers.

I think that what appealed to me so much about SDL when I first started reading about it was that it doesn't try to do everything. It just does the stuff that every game has to do on any machine or OS and then gets out of your way and lets you write code. It lets you take a program that you wrote for Windows and recompile it to run on Linux, or Mac OS, or even on palm tops, and vice versa. It provides what you need while hiding tons of details. If you run on Windows, SDL is layered on top of DirectX. If you run on Linux then SDL is layered on top of a X and several other libraries. The key is that “it just works.” I spent several months writing test programs both as a way to learn SDL and to try to find bugs in SDL. In all that time I only found a couple of minor documentation bugs and what I would call a miss-feature for which there was an easy work around. I tried ridiculous things with SDL, such as writing a program that used 10,000 timers, and wasn't able to break it. Every time I found what I thought was a bug it turned out to be either the result of minor errors in the documentation of my misunderstanding of the documentation. The one time I thought I had found a serious bug in SDL it turned out that it had already been fixed.

SDL is small, portable, and reliable. It does what you need and then gets out of your way. The basic philosophy of SDL is a combination of “lean and mean” and “Keep It Simple.”

What do you get from SDL?

Community

The SDL community is one of the most positive and most responsive communities I've seen on the net. Led by Sam Latinga with the help of a dedicated group of volunteers the community creates a steady flow of new projects, new add ons for SDL, steady improvement of the code, and ports of SDL to new platforms. The SDL mailing list is a constant source information about SDL and game programming in general with a minimum of flames and fights. The mailing list archives represent an enormous resource full of information about how to use SDL to solve game programming problems.

Set Up and Shut Down

Every operating system makes the programmer write some amount of code to find out what the OS will let you do and what the hardware can do. Then, you have to write more code to actually set things up the way you want them. You have to set the graphics modes, initialize the sound system, check for a mouse and a joystick, and on and on. Then when the game is over you usually have to clean up nicely and tell the OS you are done with whatever you were using. All of this code is pretty much the same for every project. SDL gives you a simple way to find out what the hardware can do and then with only a couple of lines of code you can set it all up. Cleaning up at the end takes even less code. And the small amount of SDL code you need can be copied and reused on project after project.

Event Based Input

SDL provides input from the keyboard, mouse, and joystick, using an event based model that will be familiar to every programmer who has written code under X11, Windows, or Mac OS. The difference is that SDL will give you the same events no matter which OS you are using and SDL doesn't make you deal with all the OS specific events that just complicate the job of writing a game.

Time and Timers

Every game program needs to know what time it is and needs to be notified when an action needs to be performed. SDL provides a clean, simple, and reliable time and timer API that is both machine and OS independent. The SDL timer APIs allow the creation of thousands of timers and can be used without the worries and limitations of other timer APIs I've used in the past.

Sound

SDL provides a simple API to query the capabilities of the sound card and all you need to produce low latency sound on any device. While the support is minimal it covers everything you actually have to have to generate sound. In this way it sticks to the lean and mean philosophy of SDL. On the other hand, there are high level sound libraries for SDL and with the way the SDL community works there are new ones coming along all the time.

CDROM

SDL provides an API for reading and playing tracks on a CDROM. Can't beat it.

Graphics

SDL gives you a choice of how you want to do graphics. You can get at the raw pixels and do pretty much anything you want with them, or you can use OpenGL to do hardware accelerated 2D and 3D graphics. The first approach works on every device out there, and since OpenGL is available for all 3D video cards it is a safe and portable way of doing high performance 3D graphics in a device and OS independent way. SDL takes care of setting the video modes, getting access to the frame buffer, if you use it, initializing OpenGL for you. SDL takes the pain out of setting up full screen graphics modes so commonly used in games, but it can set up windowed games too.

Networking

SDL includes a low level networking API that lets you set up and control both TCP/IP and UDP/IP sockets. The API is similar to the UNIX and Windows networking APIs. The difference is that it only lets you use network features that are common across all the supported operating systems. And, the API takes care of a lot of the low lever grunt work that makes setting up and managing network connections such a pain.

Threads

SDL provides a thread API that looks like a simplified version of pthreads. SDL threads provide all the basic functionality that a programmer needs in a thread package while masking the low level details that confuse so many people and make threaded code development so difficult. SDL threads are supported on all operating systems that support both threads and SDL.

What is the down side?

The only down side I've been able to find – I'm so cynical I look for the down side first – is the documentation. I have found a few errors and some of the documentation is rather skimpy. But, that is a small price to pay for this great library. The problems with the documentation are more than made up for by the ability to read the code and to read the code of many professionally written sample programs.

Some people will consider the rules you have to follow to comply with the LGPL license to be a down side. I don't consider it to be one. Complying with the LGPL rules is simple and adds little if anything to the cost of development or the cost of supporting a game.

What does it cost?

SDL is free. It is free as in beer and it is free as in freedom. SDL is released under the LGPL which requires that you follow a few simple rules to ensure that everyone always has free access to SDL. As long as you follow those rules you can use SDL.

Where can I get it?

WWW.LIBSDL.ORG is the main web site and distribution point. Everything you need to get started with SDL is linked from the site. Start by reading the FAQ file for the version of SDL you will be starting with and continue exploring the site from there. If you can't find what you are looking for use the site search function.

What's in it for me?

For professional game programmers SDL provides a clean library that can save you development time, increase the reliability of your final product, and give you the opportunity to sell your game on more than one kind of machine and operating system. But even with all the advantages that SDL gives to professional programmers, hobbyist, and beginning game programmers, have the most to gain because SDL lets you concentrate on writing your game rather than on the details of the operating system. And, because you can get started using SDL without having to spend hundreds or even thousands of dollars on software development tools.

Every day on my mailing list and by private email I get requests from people all over the world who want to write games, but don't have the money to buy commercial software development tools. Using SDL and Linux+GCC+OpenGL you can develop a game without having to spend even one dollar on development software. Even on Windows, you can use SDL+GCC+OpenGL to write high performance games without having to pay for anything but your computer and the copy of Windows you run on it. SDL lets the beginner and the hobbyist develop games using free tools and then, if they develop something with commercial potential, port it to an OS such as Windows or Mac OS where they can reach a larger audience. Not only is the code the develop portable, but the skills they develop are portable as well.

In other words, SDL can save you time and money and help you reach a wider audience for your games.