Crash Course in SDL
Intro
Game programming has gotten more complex in recent years. The market's
voracious thirst for better, faster, prettier entertainment has pushed the
state-of-the-art at breakneck speeds. As a result, multiple programming
interfaces have sprung up to drive the technology, each with their own
bugs, versions, drivers, and quirks. The game developer is compelled to
create and maintain several codepaths just to function on all her customers'
systems.
Another trend is emerging, too. In the past few years Linux has come to
the public's attention as a viable alternative to Windows, and Apple has
aggressively improved both their hardware and operating system. Thus, users
are breaking off from the mainstream to explore other platforms in
unprecedented numbers. While nothing has eroded Microsoft's dominance, these
transient users have changed the landscape: there is now a real financial
incentive to target more than just Windows, for those willing to be first
into these markets.
Now the amount of code our poor programmer is writing is increasing
exponentially. Given enough targets, this becomes an exercise in driver bug
workarounds and not game development. Production time and costs skyrocket as
a result, bug reports flow in, and customer satisfaction plummets while coders
wrestle with platform glue and corner cases.
Simple Directmedia Layer (SDL) is a software library that strives to
remedy these problems, allowing the game developer to write games and
not glue.
Why SDL?
SDL is a cross-platform API. The same SDL code will generally
work identically on all supported platforms. SDL currently runs on
Windows, Linux, MacOS 9, MacOS X, and various Unix, embedded, and
lesser-known operating systems. Chances are, if people are playing
games there, SDL supports it.
SDL is easy to use. Platform-specific APIs, like DirectX,
Quartz, and Xlib tend to have high learning curves due to complexity
masquerading as flexibility. They are generally targetted at a lower
level than the game developer needs, under the guise of higher
performance. The end result tends to be hundreds of lines of
boiler-plate code crammed into the application and/or unhandled corner
cases that the game developer shouldn't have to care about in the first
place. SDL is designed to hassle the programmer as little as possible
without surrendering crucial functionality. Getting up to speed with
SDL is trivial, even for complicated scenarios.
SDL is fast. SDL tries to find the fastest means to accomplish
its goals where it counts: at runtime. This is reflected in both the
API design and the internal implementation. SDL takes advantage of SSE,
MMX, 3DNow!, Altivec, and other such technologies when it can.
SDL is accomodating. Not interested in the ugly details of audio
sampling rate or graphic bit depths? SDL will bend over backwards to
hide them. There is no need to write, debug, and optimize a million
different audio conversion functions; just feed the library data in
your preferred format and forget about it.
SDL handles all the workarounds. On Windows, if a user has buggy
DirectSound drivers, SDL can use the waveout device instead. On Linux,
if X11 isn't available, SDL can try the framebuffer device (or several
other things, as appropriate). SDL makes a concerted effort to
accomodate a user's unique system requirements.
SDL is free. There are no licensing fees or royalties required
to use the library. The source code is available under the GNU LGPL
license. There is no vendor's agenda or arbitrary release schedule
delaying a Big Important Bug Fix. Developers can get under the hood if
they wish.
SDL expands and shrinks. On most systems, unnecessary drivers (or
even entire subsystems) can be removed from SDL, if code size is a
concern. SDL is largely focused on basic platform independence, and
thus avoids being a game developer's kitchen sink. Instead, extra
functionality is packaged as seperate libraries that are layered over
SDL itself. Examples of such packages include media file decoding,
high-level audio mixing, GUI toolkits, and complex graphical effects.
SDL is well-documented. There exist complete HTML documentation,
manpages, online articles and several print books dedicated to using SDL to
its fullest. Unlike other APIs, developers will have all the resources they
need at their fingertips.
By Developers, For Developers: SDL sprung to life out of the
explicit needs of game developers. The maintainers eat their own dog
food, so to speak, and ship big-name products with the library. SDL has
been a favorite of Unix programmers, demo scene hackers and indie game
houses for years, and has been gaining commercial acceptance recently.
The primary developers and a sizable community are all easy to contact,
and are amicable and eager to help. Bug fixes have an impressive
turnaround time, frequently within hours.
Who uses SDL?
The Unreal Engine and Torque Engine ship with SDL support. SDL has been
retrofitted into almost every other major engine, including all
three Quakes, Lithtech, and the Serious Engine. SDL-powered titles
using all of these engines have shipped commercially.
!!! TODO: list some titles.
Bird's-eye view:
SDL is seperated into several subsystems. They are:
- Video. Optimized 2D software rendering, and OpenGL support for 3D graphics.
SDL hides the system specific issues of OpenGL, such as context creation,
making your OpenGL code truly cross-platform out of the box.
- Audio. Sound playback works on callback system, where you feed the audio
device as required. SDL will handle audio format conversion for you. If a
callback is too lowlevel for you, there are add-ons that layer on top of
this to give you "fire and forget" mixing.
- Input. Mice and keyboards and joysticks, etc. SDL gives you an event queue
that any game developer should be familiar with. Hardware can be polled
directly, as well.
- Timing. Alarms and ticks, etc.
- Threading. Thread creation, serialization, etc are all offered in a
cross-platform manner through SDL.
- Other nice features, such as CPU feature detection, byteswapping, etc.
Saving time, saving money.
Simple Directmedia Layer was designed to take away the hassle, but not the
power, of game development. Developers can cut out a mass of complex
codepaths and multiple backends. Since SDL hides the ugliness, they can have
one basic path to the hardware and focus on developing the game itself. If you
want to target the Mac or Linux, you no longer need to add two more developers
(or triple the work of a single developer), since all the platform-specific
code is managed inside the library. Since SDL tends to be much easier to
learn and utilize than any specific platform's APIs, it might actually cut
development time further to start with SDL, even when targetting a single
platform. This can significantly trim production times, and thus costs.
Your developers stay focused on the game and not the operating system.
This is an ongoing theme: developer time is priceless. SDL takes strides to
keep them happy and efficient, so they can ship games on deadline and under
budget.
Simple Directmedia Layer, as both source code and prepackaged libraries, is
available for free download at http://www.libsdl.org/
--ryan.