Do I Have to Use DirectX?

If your game is on any console, even the Xbox, you already know the answer to this question. Skip ahead a bit and let the PC programmers worry about this section. The rest of you PC programmers have to consider whether to use DirectX in your game or try an alternative API for graphics, sound, input, or network communications.

Just to be perfectly clear, this section has nothing to do with how to draw a shaded polygon under Direct3D. This section is going to enlighten you about why you would choose something like OpenGL over Direct3D, or straight TCP/IP over DirectPlay. Believe it or not, the choice isn't clear-cut no matter what your religious beliefs.

Best Practice

It's not possible for me to be more tired of the religious nature of the OpenGL/DirectX debate. Any good programmer should understand what's under the hood of every API if you have to make a choice between them. Disregarding DirectX simply because Microsoft made it is asinine.

Design Philosophy of DirectX

DirectX was designed to sit between the application and the hardware. If the hardware was capable of performing an action itself DirectX would call the driver and be done with it. If the hardware wasn't there, such as an older video card not having a hardware transform and lighting pipeline, DirectX would emulate the call in software. Clearly that would be much slower.

One thing that was gained by this design philosophy was a single API for every hardware combination that supported DirectX. Back in the old days (that would be the early 1990s), programmers weren't so lucky. A great example was all the work that needed to be done for sound systems. Origin supported Adlib, Roland, and SoundBlaster with separate bits of code. Graphics were similar; the old EGA graphics standard was completely different than Hercules. What a pain!

Of course, DirectX isn't the simplest API to learn. COM is a weird thing to look at if you aren't used to it. It also seems weird to have fifty lines of code to initialize a 3D rendering surface when OpenGL does it so much easier. Herein lies the root of the religious argument: old time C versus newfangled COM. Get over it long enough to understand it.

DirectX exposes a lot more about what the hardware is capable of doing. Those CAPS bits can tell you if your video card can support hardware transform and lighting (T&L) for example, and perhaps that means you'll load up denser geometry or simply bring up a dialog box telling some loser that he needs a better video card. Your customer service people will thank you if you decide to leave the word "loser" out of the error message.

Direct3D or OpenGL

I'm not going to preach to you about why DirectX sucks and why OpenGL is God's gift. Instead, I hope to give you enough knowledge about how and why you would judge one against the other with the goal of making the best choice for your game, your team, and the good people that will throw money at you to play your latest game. I'm sure to get lovely emails about this section. Bring it on. I'm going to take a weirder tack on this argument anyway. Both APIs will get you a nice looking game. There are plenty of middleware rendering engines that support both. What does that tell you? It tells me that while there may be interesting bits and pieces here and there that are unique, the basic job of pushing triangles to the video card is essentially equivalent.

You don't have control over the quality of the driver. I'm sure we could find OpenGL drivers that suck, and we can certainly find Direct3D drivers that never should have seen the light of day. Given that unfortunate reality, you'd like to choose the API that has the best drivers for all the people who will play your game.

If you have a hard core title like Unreal Tournament you're pretty safe in choosing OpenGL, since the drivers for high end cards tend to have a high quality. Of course, the Direct3D drivers for these same cards are going to be equally good, since they're high-end cards after all. Your choice gets murkier if your game has a wider appeal and perhaps runs on older machines. It's a safe bet that there are more video cards out there that have Direct3D drivers than OpenGL drivers, and that on the low end cards the Direct3D drivers are going to be better.

Why is this true? The video card companies making low end cards had to make a choice too, and allocate resources to write drivers. They generally chose Direct3D first and got that driver out the door and on the install disk. The OpenGL driver might come later on the website, if they had time and resources to do it. Again, this points to the fact that a hard core audience will likely have OpenGL drivers on a rocking video card, because they sought it out.

The mass market went where they were told: Direct3D. I guess that's where you should go too, if you are doing a game with mass market appeal. Hard core games can make whatever choice they like.

DirectSound or Miles Sound by RAD Game Tools

For sound and video, I don't look any farther than RAD Game Tools, Inc. The Miles Sound System includes full source code, has a flat license fee, and works on Win32 and Macintosh. The Bink Video tools are cross platform and support Xbox, Gamecube, Win32, and Macintosh. Check out the latest at www.radgametools.com. It doesn't hurt that RAD has been in business since 1988 and has licensed their technology for thousands of games. They are probably the most used middleware company in the industry.

Miles can use DirectSound as a lower layer. This is quite convenient if you want to do some odd thing that Miles can't. The real nail in the coffin for DirectSound is that it doesn't include the ability to decode MP3 files. Part of your license fee for Miles pays for a license to decode MP3s, which are a fantastic alternative to storing bloated WAV files or weird sounding MIDIs. Bottom line, do yourself a favor and get Miles for your game.

DirectInput or Roll Your Own

DirectInput encapsulates the translation of hardware generated messages to something your game can use directly. This mapping isn't exactly rocket science, and most programmers can code the most used portions of DirectInput with their eyes closed. The weirder input devices, like the force feedback joysticks that look like an implement of torture, plug right into DirectInput. DirectInput also abstracts the device so that you can write one body of code for your game, whether or not your players have the weirdest joystick on the block.

DirectPlay, TCP, or UDP

This decision used to be easy. Action games were UDP. Most other Internet games were TCP. Nothing used DirectPlay. Since DirectX 8 was released, this decision isn't quite so clear cut, and it has to do with the way DirectPlay has changed in the last few years. When DirectPlay was first released its major breakthrough, if that's not going to far, was to provide a standard API by which you could communicate through any connection: modem, serial cable, IPX, or IP. Almost every multiplayer game out at the time used IPX for LAN games or the Internet protocols: TCP and UDP. I never actually played a game modem to modem and I never wanted to.

Client/server games under earlier versions of DirectPlay had horrible performance. I'm not talking about ten or fifteen players here, I'm talking about thousands like on Ultima Online. The login system was the only Windows based server and we used TCP with good old WINSOCK2. Its performance wasn't fantastic either, but it was light-years ahead of DirectPlay.

It turned out that the implementation of some critical Winsock statements, namely select(), had increasingly bad performance under a high number of connected clients. It turned out that there was a better way under Windows NT, and it used an interesting method called I/O completion ports. Without dragging you into too many details, suffice it to say that this method didn't degrade linearly with the number of connected clients. It easily handled thousands of simultaneous connections per server. It actually performed better under similar circumstances than Berkley sockets under Linux.

By the time DirectX 8 was going through its API review, it was obvious to the DirectPlay engineers at Microsoft that something had to be done. The entire module was rewritten from the ground up, incorporating optimizations such as I/O completion ports if they were available and made excellent progress towards an API that was actually more useful than straight TCP or UDP.

This is especially true for those programmers unfamiliar with Internet programming. Getting a socket set up between two computers is a piece of cake. Anyone could do it. What's not so simple is what to do when the connection is dropped. If it was unintentional you'll need to keep the socket session alive to reestablish it when the client reattaches. An intentional drop will have to be recognized eventually and cleaned up. There are plenty of special cases that must be covered even under simple TCP, and they will drive the beginner completely crazy. Don't go without a license.

It's important to know that DirectPlay is a UDP based system that has the ability to send guaranteed messages a'la TCP, without all the overhead of TCP. That won't convince the UDP hard liners out there but I hope it entices them to take a look at it.

DirectShow versus Bink

Someone out there is going to think someone at RAD Game Tools paid me off to constantly squawk about the virtue of using their wares in your game. I'd happily accept a couple of Bink licenses for the effort because it simply is the easiest way to get a big fat movie squashed into something that can make a nice intro. DirectShow is a streaming multimedia API designed to play back video files using codecs that are already installed in the machine. This is not going to help you when you're tight for space.

Bink is a decompression and playback API that comes with its own compression tool. The compression is gamer friendly, too. Unlike other codecs, it allows you to do nutty things like skip every other horizontal line of video. Sure, it looks a little darker but it compresses to half of the original size. Use Bink and save yourself some grief.

DirectMusic versus Rolling Your Own

DirectMusic was designed in the hopes that the CPU could choose the right music to play given certain input parameters. When I heard about this API for the first time I thought that the DirectX engineers had too much time on their hands. There might have been something of a use for it at one time, when computer music was mixed on the fly from bits and pieces just a few measures long.

Most music is digitally recorded, and plays for quite some time before changing to another piece. Usually transition measures exist if you have to pick up the pace and fly into a hard banging combat tune from something quieter. That might make you want to look into DirectMusic to see if it will help. Resist the urge.

Music can give players a huge emotional charge. You can give them a clue that something wicked this way comes. A good composer is going to know how he wants the various pieces to transition and he'll throttle you if you give this control away. If you don't believe me, play the DirectMusic samples yourself. If they're good enough for you, more power to you.