Chapter 11: Special Considerations for Developing Windows Games

Overview

My first experience with Windows programming was Windows 3.1, a 16-bit cooperative multitasking operating system. Coming from DOS 5 programming, the weirdest thing for me by far was getting used to a message passing architecture instead of a process-based architecture. One annoying thing was having to learn the huge Win16 API. I had just become comfortable with ANSI C runtime, and new functions started falling out of the sky. Windows 3.1 had no fast way to draw bitmapped graphics—the curse for any game developer. Some operations, such as blitting with a color key, were nigh impossible. Actually, this wasn't impossible, but the calisthenics required to make a color keyed sprite under the GDI were insane.

The year was 1994, and Microsoft had just launched a serious initiative to court the computer game industry. Microsoft was bored with their total domination of the desktop business software industry and they wanted to enter our homes. They had the right idea: target games first and everything else will follow. Someone at Microsoft had a brilliant idea of gathering a collection of computer game programmers from the most successful companies of the day for an intensive workshop at the Microsoft campus in Redmond, Washington. The invited programmers lived in Redmond for a short while and helped the DirectX 1 team come up with the API for DirectDraw.

A Tale from the Pixel Mines

I wasn't one of the programmers to attend the workshop, but a few of my fellow collegues from Origin System were invited. They developed a little arcade game where you roamed the labyrinthine halls of Microsoft shooting Microsoft engineers as they popped out of their offices! I heard it was a lot of fun, and especially popular with the original DirectX engineers.

This technology was unleashed at the 1995 Game Developer's Conference in San Jose with a little demonstration of a simple Windows game called the Fox and the Bear. Sporting a gleaming white lab coat and grinning ear to ear, a jubilant Alex St. John demonstrated, for the very first time, a Windows game that could run full-screen at a blazing 60fps. To give you an idea of how cool this was, imagine taking a ride in my brand new car and the first thing I do is push a button, lift off the ground, and enter low earth orbit.

This event was a turning point in the computer game industry, much more so than the announcement of a new platform. Unlike Sony, Nintendo, and others launching their new hardware every few years to the oooos and ahhhhs of everyone, DirectX hit everyone square in the chest because developers could begin creating games for the new Windows platform immediately. The console groups had the same tight rein on developers that they do today. It takes a lot of work to become an approved developer for a console. At the same time, Windows 95 was just beginning its final approach. Most developers had beta copies of the new Windows operating system, codenamed Chicago, and were figuring out how cool it really was. First, it was a true 32-bit operating system, at least mostly it was. There were some 16-bit components here and there, but most programmers could ignore thunking—the process that describes the transition between 16-bit and 32-bit code.

The 32-bit memory space was really a leap, since the biggest single data element in a 16-bit system was 64Kb. That's not nearly big enough to hold a single 640x480 background sprite. For those of you now who are making the transition to 64-bit, it won't be nearly as cool. There aren't very many game data structures that are pressing on the 4Gb barrier. Back then we needed the extra space now, so much so that Ultima VII wrote a 32-bit memory manager for DOS 5.

The other real advantage was operating system supported multithreading. This was a convenient departure from our DOS-based solution: We trapped the timer interrupt and wrote a simple multitasker ourselves. Now we could have our threads without resorting to heavy metal programming, meaning that even I could do it. If you are getting the impression that Windows 95 solved all of our problems and we were saved from the messy burdens of DOS programming, you're somewhat correct. It did solve some sticky problems. It wasn't programming nirvana, however.

One source of this programming hell was the fact the operating system group at Microsoft never saw DirectX as a core component of the operating system. The DirectX group was managed under a completely different business unit, and was essentially treated no different than any other applications developer within Microsoft. This odd structure has led to DirectX being a bit of a rogue technology within the operating system, which is why DirectX itself is not Windows logo compliant in all aspects.

Win32 platforms are true multitasking, which means for the first time I can switch over to Excel or Word in the middle of my game, and convince my boss that I was a diligent and productive employee. Well, I could do this if the game was written right, which most are not. All Win32 applications have to handle a core set of messages properly to live and play nice with all the other Win32 programs. Games have an especially hard time with this because of what players can do to the machine while they hit the Alt-Tab key to select other tasks, or even worse they might change the desktop graphics format from 16-bit to 24-bit.

The innovation cycle for Microsoft is fast, much faster than the console world. It's a lot easier and cheaper to burn DVDs than etch silicon. This means that Microsoft can publish a new operating system version once every two years or so, whereas Sony gets to work hard for three or four years before the new PS{n+1} comes out. Console developers never have to worry about backwards compatibility for this reason. After all, who wants to play a game that's four years old? Desktop PCs have a long life, five to six years, and programs must be backwards compatible to some extent. This compatibility requirement with older operating system versions and old hardware makes desktop game coding a serious pain in the ass, and debugging and testing is certainly no easier as you'll learn in Chapters 12 and 15.

This entire book has a Win32 bias, but nowhere will you see this bias clearer than in this chapter. I've tried to concentrate the lion's share of Win32 witchcraft here, leaving the rest of the book to talk about more portable concerns. If you never program under Win32, don't stop reading. It might give you some good ideas anyway. If you are a Win32 game coder, this chapter may be the most important part of this book.