Since I spent the last 6 months or so getting geeked about web development, SVG, JavaScript, Ajax and XML. I think it's about time I shift my focus back for a little while on some standard C++ game development for the desktop. I find that my mind naturally migrates every so often (usually 6 months) between interests/hobbies that I have. It's like my brain is saying that it needs a breather from obsessing about one thing so it's time to obsess on another. Mild OCD anyone?
So for the past week, I've been hacking away at the code for Ten Nights of Killing and Mayhem when I have some free time. Development is also being spurred on by the fact that Jeff Sinasac has some time to generate some new sounds and graphics for the game. Fresh resources are always good incentive to get more work done.
"Ten Nights of Killing and Mayhem" was originally a board game that Sinasac and I designed (with the invaluable help of a few others) in high school (1991). In retrospect, the subject matter is hardly politically correct, maybe even disturbing, but it was a fun creative outlet for us during a time when we needed it. About a year later (1992-ish), Sinasac wrote "Ten Nights" as a DOS-based game. Then maybe a year or two after that he rewrote it to use enhanced graphics/sound (though still DOS-based). By this time the game resembled a primitive top-down X-Com in its gameplay and approach.
The DOS-based game used the Borland graphics libraries (Borland Graphics Interface or BGI), but since the migration from DOS-based systems to Windows-based systems in the mid-nineties, such graphics libraries are long past their point of usefulness. With the advent of modern media technologies, something new was needed.
Porting directly to DirectX was one option, but DirectX is heavily COM-based and would have required drastic rewrites of a non-trivial codebase. My goal was to get "Ten Nights" up and running as quick as possible in Windows (and then later enhance it).
Simple DirectMedia Layer (SDL) is similar to DirectX in that it providing access to graphics, keyboard/mouse event handling, audio, etc for games. Yet SDL is a cross-platform library and is (therefore) not dependent upon the user worrying about COM, Window handles, display context, and the like. In essence, you can disengage from learning heavy platform-specific code and, once you know a little SDL, just work on your game. You also have the side benefit of easing ports to other platforms.
Actually SDL's approach to 2D graphics is fairly minimal. It allows you to configure your video settings (resolution, colour depth), load images (Windows BMP only), obtain pointers to surfaces that represent image data (both onscreen and in-memory), and perform blits to the screen. The blits can be standard copies, colour-keyed copies (to provide simple transparencies or sprites) or more complex alpha-blended blits (to provide opacity and blending effects). There are a couple other lesser-used functions in SDL, but from a graphics perspective that's about it.
In some respects, since SDL needs to be cross-platform, it (unfortunately) needs to provide a "least-common denominator" approach for basic graphics support. For instance, SDL does not even provide a function to get or set an individual pixel colour, you actually have to write your own (or use the code provided in the SDL documentation here). However, it makes up for this sparseness by providing hardware accelerated support on platforms that can do this (for example, SDL uses DirectDraw on Windows platforms for fast hardware support on video cards that support this). SDL also has some good extension libraries you can add onto that provide you with richer functionality (more on these in later entries).
In addition, SDL provides the benefit of allowing you to handle events (keyboard, mouse, timer, joysticks) and audio in a cross-platform manner, which is a huge benefit if you're thinking of writing games once that can run everywhere. You can pick and choose the components that you need from SDL and there's not a lot of complicated "initialization" steps that need to happen before you can do something useful.
SDL does not provide support for 3D graphics, but it does integrate nicely with OpenGL. For example, you could use SDL to handle all your window initialization, event-handling, audio and then use OpenGL for your 3D graphics.
SDL is pretty easy to pick up since there's not a lot of complicated things to learn. Everything is straight-forward C-style API calls and you've only got to learn about a few structs (the most important of which is SDL_Surface) before you can start doing something useful.
Anyway, weighing the pros and cons of SDL, early March 2004 I decided to learn about SDL and work towards porting the old games to SDL. Was it spurred on by my anxiety related to my wife being due with twins that month? Was this my last-ditch attempt to reclaim my geek programming life and relive my high-school glory days before I became a family man? More coming in Part Two...