“DirectX was a strange example of a strategy that succeeded in several ways at once when it was expected to fail on more levels than it did.”
-Alex St. John
Since the dawn of personal computers there has been consistent growth in speed, memory (RAM and ROM), data storage, and graphics. The quest for better graphics dovetailed with the development of more and more powerful CPUs, specialized graphics chips and cards, and high-resolution monitors. During the 1980s, graphics on personal computers evolved relatively rapidly from the 4-color CGA (Color Graphics Adapter) standard in 1981 to the 16-color EGA (Enhanced Color Adapter) in 1984 to the 256 color VGA (Video Graphics Array) in 1987. These standards were succeeded by Super VGA and, finally, XGA, which could display at resolutions up to 1024 by 768. Following XGA, maximum resolutions continued to increase at a steady pace.
Computer graphics were never easy to produce in the early days of computing. Graphics pioneers had to work directly at the machine level or in assembly language to produce results. They worked not only with limited color pallets, but with extreme memory limitations. And yet, observing the evolution of graphics in computer games alone shows a steady improvement from the crude graphics of games in the 1970s, such as those seen on the Atari 2600, to vastly more detailed graphics in the 1980s, culminating with the 8-bit Nintendo Entertainment System. In the 1990s, 16-bit systems like Sega Genesis and Super NES were brighter, faster, and more detailed than anything before, and during the 1990s, games showed continual graphical improvement, not only on consoles such as PlayStation, Nintendo 64, and Sega’s final console, the Dreamcast, but also on PCs. But achieving fast, efficient and competitive graphics on PCs did not come easily.
When it was released, Windows was an abominable platform for multimedia, and games especially, and while DOS was no picnic to work with, Windows was a sluggish quagmire by comparison. DOS programmers worked directly “to the metal,” meaning that their games communicated directly to the CPU and graphics processors without any intermediary programs. As a consequence, although it was challenging to program games in DOS, it was possible with good software engineering to coax the maximum performance out of the hardware. Windows required various layers of programming of its own to manage the graphics and multiprocessing it required. Simply put, this meant that early Windows put a lot of layers of interference between the game programmers and the metal. Where these layers did not appreciably interfere with the operations of office types of programs, they were death to any game that required fast graphics and fast responses.
As graphics resolutions increased, opening the door for more detailed and realistic images, the next great innovation in graphics involved adding a third dimension. The concept of 3D graphics was not new in the 1990s. Programmers had figured out how to approximate 3D graphics with wireframes, such as in the 1980 Atari game Battlezone, and with perspective, as in the famous game Zaxxon, which faked the appearance of three dimensions. However, 3D graphics as we know it today, which is seen all through games, animation, and composited live-action films, evolved in steps.
Early workstations, like the ones from Silicon Graphics Inc. (SGI) were among the first to produce high quality 3D computer images and animations, but these workstations cost minimally hundreds of thousands of dollars and weren’t meant for consumer use. 3D on home computers was feasible, however, but it would require new hardware and software solutions to become practical and affordable. Again, Windows was not ideally suited for handling 3D graphics, especially in games, but it was a priority at Microsoft that some solution be found. The path to fast graphics and 3D on the desktop spawned several competing visions at Microsoft. There was no single, unified initiative.
OpenGL
OpenGL was the main standard in the mid-1990s for 3D computer graphics. It had been developed by researchers and engineers at Silicon Graphics Inc., without doubt the most advanced 3D experts in the world at the time. It was developed from SGI’s high-end workstation API, IRIS GL, but it was released as an open standard in 1992 by its developers, Mark Segal and Kurt Akeley.
OpenGL represented a consistent standard that would work with consumer machines. Where IRIS GL required certain hardware components to use all of its feature—components only found on SGI’s high-end workstations—OpenGL allowed developers full functionality by using software solutions where the hardware was not present. Many people, including some at Microsoft, believed that supporting OpenGL was the best option for the industry and for Microsoft, but there were others who saw potential flaws with OpenGL, and they looked for new solutions—Microsoft solutions.
One of the flaws of OpenGL 1.0 was that, even though it was intended to work with lower-end systems, it did not work very well. Many developers, including id Software’s 3D guru John Carmack, rejected OpenGL at first. Inside Microsoft, one of their talented and outspoken engineers, Chris Hecker, also rejected it at first, later changing his opinion. He wrote on his blog, “The conventional wisdom used to be that OpenGL was inherently slow—too slow for games—and that Microsoft had to design their own API.” Hecker claims that nobody understood the technical issues at the time except for high-level workstation engineers who were not focused on 3D games. Like Hecker, Carmack eventually switched his stance and came to back OpenGL a few years later, escalating an ongoing battle against Microsoft’s internal solution. However, back in 1994, Alex St. John had already begun searching for someone who could help him create a 3D API for Microsoft that could rival OpenGL.
WinG
In initially rejecting OpenGL, Hecker decided to create his own 2D drawing API, which he called WinG (pronounced “Win Gee”). Simply put, WinG was designed to help address performance problems with the Windows GDI allow development of faster games for Windows, which, because its graphics architecture had been designed for office applications, was simply not able to handle the demands of animation and interactive applications such as games.
Hecker wrote an explanation of how WinG worked in an article for Gamasutra in 1997. You can read it, complete with technical details at this address: http://www.gamasutra.com/viewlfeaturel3l99la_whirlwind__tour_of_wing.php
As Hecker explains in his article, there were two ways to update screen data, through bit level transfer (blt) or page flipping (loading an entire screen in the background and then “flipping” it to replace the existing screen image). Windows did not yet support page flipping, so Hecker found a way to break the major bottleneck in the system by combining the functions of write-only HBITMAPs, which is where the graphic bits are stored, and Device Independent Bitmaps (DIBs), which can be accessed directly by applications, unfortunately resulting in bit transfers many times slower than DOS BitBlt. By creating a hybrid of the two, an object which he called WinGBitmap, Hecker was able to work around the limitations of Windows and achieve DOS level speed.
The WinG DOOM Demo
Hecker managed to produce a Windows 3.1 DOOM demo using WinG that turned heads at Microsoft and gained him a lot of notoriety. The demo video showed the ultra-popular 3D game DOOM running at an astounding 60 frames per second. After seeing the demo, Rick Segal turned to Alex St. John and said, “Alex, this thing’s got people really excited. Can you turn it into a gaming technology?” And St. John said, “I betcha I can do something with that.”
According to St. John, Hecker was brilliant, but there was a fundamental problem working with him. “He was very young, and he liked fucking around, and so he was having fun getting the fame and the attention for it, but there was a huge amount of really tedious work left to do to finish it… He didn’t want to do it. He didn’t have the attention span for it.”
St. John, meanwhile, was evangelizing WinG, and he managed to get several game companies to use the technology. He’d tell them, “Hey, Hey, we’ve got this great new API. It’s gonna make your games work great in Windows 3.1 that couldn’t work before.” There were about two dozen games scheduled for Christmas of 1994, all of which would need to have a completed version of WinG by September if they were going to be released in October, before the all-important Christmas season. There were some big names, too, including Disney’s upcoming title, The Lion King.
According to St. John, Hecker simply flaked out. He wasn’t working on it. Telling Rick Segal, “I’ve got a serious problem here. It’s going to be a fucking train wreck if it’s not finished on time,” St John also spoke with Craig Eisler who Segal agreed to put on the project with Hecker. “Eisler is a giant,” says St. John. “I’ve never seen an engineer who can do what Eisler could do. He’s astounding. And what’s amazing is that he was ever in evangelism at all, because of his programming talent. What a waste having a guy like that talk to anybody.”
Eisler, along with Todd Laney, managed to get the project done on time, although according to St. John, Hecker was “bucking and screaming the whole way. He was very bitter about the treatment he got.” (I did reach out to Hecker, but he wasn’t interested in talking about the old days.)
Ultimately, 24 Windows 3.1 games launched for Christmas ‘94 using WinG. The most memorable of them was Disney’s Lion King… memorable, but not in a good way as we will see.
Porting DOOM
While WinG was being finished, Alex St. John was thinking about DOOM. The problem with Hecker’s video is that it only showed graphics, no game-play, no networking. In other words, it was a graphics demo, not a full DOOM port. The logical next step was to complete the job by porting the entire game while continuing the development of WinG, which at the time showed considerable promise as a solution to the problem of bringing games to Windows—including the catalog of popular DOS games that would otherwise not work on the new platform.
Eisler, Engstrom and St. John were already planning to develop a set of APIs that would deal with computer data throughput, graphics, sound, devices (such as mice and joysticks), and connectivity. What better way to uncover the roadblocks and challenges of gaming in Windows than to take a fast-paced game like DOOM and find a way to make it work?
St. John had originally helped Hecker get the source code for DOOM from John Carmack at id, but as he closely watched over the porting effort, he saw all the problems they were encountering, “making me an authority on what was broken.” St. John decided that porting DOOM to Windows should be an official project, so he made a deal with Carmack that Microsoft would do the work if id would publish the Windows version—providing that the port met his requirements.
St. John didn’t have any engineering resources, so he approached Gabe Newell, who was working on set-top box UI at the Advanced Technology Group and asked if he could spare somebody.
Radio Silence
Newell (who later would co-found Valve Software) came up with an engineer and St. John put him to work porting the game. “The guy went radio silent. Weeks would go by and I would just hear nothing. Couldn’t reach him. So finally I go by his office. The window was blacked out and you’d bang on the door, and it would be dark and he’d be sitting over his computer, like sweating… perspiring, and it would be too hot in his office and smelled stale like he’d been in there for several days. And he’d be really abrupt and angry. So you’d come in and go, ‘Hey, how’s that DOOM port going?’ and he really didn’t want anybody in his office. So I remember saying to Gabe, ‘Hey, I don’t know what’s going on with your guy here, but he’s not responsive, and he just seems holed up in here, and I have no idea whether he’s working on it or not, or what he’s doing.’ A few days later, he turned up dead… drug overdose.”
As dark as this story is, St. John still remembers how he got dinged for being late with his DOOM port and lost points on his performance review. “So the feedback is that I didn’t deliver DOOM on time because my engineer died.”
St. John managed to enlist Robert Hess, a senior engineer who he describes as “in a career stage well beyond having to indulge in coding.” Together, Hess and St. John approached the minefield of porting DOOM to Windows 3.1. “I mean Windows 3.1… Oh my god.”
Each time Hess would identify a problem, St. John would endeavor to figure out what was causing it. “So what would happen is he’d say, ‘I can’t get sound mixing to work and synchronize.’ And so then I would have to become an expert on sound mixing and synchronizing, and try to figure out why and who owned it at the company, and who was working on it, and was it getting dealt with in Windows 95, and so forth.”
Networking DOOM
Another issue that came up while trying to port DOOM to Windows was networking. At the time, the only networking protocol available in Windows was TCP/IP, and the problem with TCP/IP was that when it sent out a packet of information, it waited for confirmation from the recipient system that it had been received. This was a serious problem, as St. John explains: “To be nerdy, TCP/IP packets are guaranteed to be delivered. That is, if I send a message to your computer, nothing else gets sent until your computer replies that it received that message. For games, that’s a problem because, if a message doesn’t get delivered, it’s irrelevant anyway. I’ve got to deliver the next frame anyhow. The game can’t pause for several seconds to make sure a packet arrives. It just gets the next one. So you needed the ability just blast packets over network and have them received without responding.”
Jawad Khaki was the engineer in charge of Windows Sockets API, known more commonly as Winsock, which defined how Windows applications accessed network services. The problem was, the current implementation of Winsock only supported TCP/IP, and what St. John needed for DOOM networking was the User Datagram Protocol, generally referred to as UDP. St. John had worked with Khaki in his previous Microsoft incarnation in the Publishing division, and he knew that UDP was necessary for networking printers because using TCP/IP caused printer sharing to grind to a halt in the early days before print spooling.
What made UDP preferable over TCP/IP is that UDP didn’t require any confirmation, handshake, or even previous contact with a recipient. It could send data continually and fast—exactly what was needed for fast-paced games like DOOM. Games always had to move on to the next thing immediately, and if one packet got dropped, it didn’t matter. At the refresh pace of any game, a dropped packet, or even a few packet losses, wouldn’t be noticed.
St. John was able to persuade Khaki to expose the UDP protocol in Windows 95, which opened the door for networking games like DOOM to work on Windows, and for many games to come… such as almost every Windows game today.
Another problem with networking was how difficult it was in those days to link people together. Early multiplayer PC games required physical computers to be sharing a local network, but St. John wanted to be able to let people play over the internet. The problem was that the process in place for such connections was what St. John called a “fucked diddley mess”. “If you wanted to play one other player in DOOM over the internet, you had to call them on the phone—call your friend on the phone—agree on the IP address, do something to route the IP stack through to a modem, then you call each other with your modem and hang up, and the game would synchronize.”
The solution, which became part of the DirectPlay API, was to use a lobby server. “The way to find other people and play DOOM and connect over a modem, was you called an internet server with your modem. The game would just do it from DOOM. It would call the lobby server, find players, get their modem information, disconnect from the internet, call their phone directly, exchange the information, and you were playing. That was state of the art network gaming back then.”
An early game networking service called Dial-Up Wide-Area Network Game Operation—DWANGO—used this technology with support from Microsoft to set up DOOM tournaments all over the world. Microsoft worked with DWANGO to promote online tournaments like the Death Match 95 DOOM tournament that was conducted online and in various local venues around the country and even helped DWANGO expand into Japan, where they were very successful.
DirectPlay was important for its time, and it formed one of the core technologies behind the formation of the Microsoft Game Zone, with several ex-DRG people, such as Jason Robar and Adam Watts, going over to help form it. St. John even brought in an old friend from Harlequin—Ian Robinson—to help write the DirectPlay API.
Virtual Memory
Even when not networking, many games need to move data very quickly, but Windows was not originally designed to move data particularly fast. It was designed to run simultaneous processes, however, so there were generally many drivers running simultaneously without time constraints. “So everything waited for a driver to finish whatever fucking around it wanted to do before it would respond. So drivers in Windows 3.1 and Windows 95 could really shape a game’s latency. Even if you had fast video graphics—you could draw the screen at 60 frames a second—you could get a one- or two-second lag just because the network driver or something decided count its fingers and toes for a while before it returned control to the operating system.”
St. John’s solution was to put into Windows the ability to hard lock a chunk of memory “so that the OS couldn’t just decide to do some virtual memory shit and slow down,” as well as the ability to allocate a much higher priority to specific processes.
The Mouse
St. John brought Ian Robinson from England to help with DirectPlay, and he also brought another Brit to help build DirectMouse. As was so often the case, using the mouse in games such as DOOM was a nightmare in Windows. “The Windows 3.1 messaging architecture was so slow that you would move the mouse to spin the screen around, and even though the screen could spin in WinG at 60 frames a second, the mouse queue might check messages three or four times a second, so you’d aim at somebody, click the mouse button and they’d move out of the way before the game got the message and fired at them.” DirectMouse once again cleared away the competing processes and allowed for realistic game performance. For joysticks, Craig Eisler wrote DirectInput for similar reasons.
The original name given to the suite of APIs Eisler was developing was the Manhattan Game SDK.
Sneaking in Changes
“You’re not in charge. You have to sell everybody on anything you want.” –Cameron Myhrvold to Alex St. John
Knowing that Windows 3.1 was soon to be history, St. John’s bigger concerns centered on Windows 95, which was still being completed. Working on the DOOM port exposed several problems, which St. John was trying to fix in Windows 95—code-named Chicago—before it was too late, even though, officially, it was too late. At that time, no new features or changes were allowed, only official bug fixes.
One of the problems that showed up was in how Windows handled CD drivers. The Windows 95 driver architecture had been designed to assume that CD ROMs would be used to play videos, and so they used a cache to load data serially. “It just was slow as hell. Everything just bogged because this cache loaded everything serially, and I needed to turn it off for games.”
At the time, St. John had no official status on the OS team, but that didn’t stop him. He had learned from the beginning how his job worked. “Cameron Myhrvold said this to me when I took the job to lead strategy for all of publishing. I said, ‘Oh boy. That sounds important. What authority do I have to do that?’ And the answer was, ‘None. Your job is to persuade them. You’re not in charge. You have to sell everybody on anything you want.’”
“I used to try to do it by process,” St John says, “but I quickly gave that up and what I really would do, I’d secretly find the actual individual engineer, and I’d go into their office and say, ‘Hey, I need you to fix this. Can you get right on this for me?’ And bypass their management, their process and everything. Remember, it was too late to make changes to Windows 95. Features were banned. Everything was banned. So if I want something done, I had to slip it in under the rug.”
This is exactly what he did to fix the CD problem. He convinced the engineer in charge of the CD drivers to implement two changes—adding the Autoplay API that St. John had written himself, and some code that made it possible to disable the cache and run games directly from the CD, which also used code he had written. Humongous Entertainment’s Freddi Fish was the first Autoplay CD ever published. It was also a WinG title.
Once the changes had been made to their DOOM port, he would have Hess test them to see if they were effective. But despite their efforts, the port was a failure. St. John says, “It was a disaster. Hess was brilliant. Years later he got upset with me for saying it was a disaster. He took it personally. But it wasn’t you, Hess. Everybody knew you were trying to do something impossible.”
St. John saw the problems, but there were no available solutions at the time. “The problem was the latencies were just huge. The audio just drifted out of sync with the sound effects and out of sync with the network, and there was nothing Hess could do to fix it. You know, it ran enough to go, ‘Well, you can almost run DOOM on Windows, but it’s clearly not as good as the DOS version.’ Obviously not as good as DOS, and that was a problem. Even knowing it wasn’t up to the highest standards, but still respecting the work Hess had put into it, St. John did show it to Carmack, who, predictably, said, ‘No. I can’t publish that.’”