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.