Advancing Linux game development through better multimedia management
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."