Finding and Fixing Direct3D

ft. a hopelessly biased account of the OpenGL v Direct3D war

Copyright (C) 2025 by Nicholas Wilt. All rights reserved.

This article is a continuation of the earlier account of how I joined the DirectX team.

Getting settled into the DirectX team, I got to know the folks who’d been featured in the Micronews article, and many others. Besides Craig and Eric, Bob Heddle and Ajay Jindal worked as program managers, responsible for finalizing product plans and then working with development and QA folks to bring it to market. Colin McCartney, a Scotsman who’d worked at a company Criterion Software, was one of the principal developers on DirectDraw. Jeff Noyle, a mild-mannered Welshman, also worked on DirectDraw. Jeff Norris, a QA lead, ran a huge display lab with hundreds of graphics cards, computers to plug them into, and a two-tiered hierarchy of monitor splitters driving a dizzying array of monitors. His guys were better at using the Windows plug-and-play subsystem than anyone I’ve ever seen, deftly installing, reinstalling, and updating display drivers when they weren’t installing a fresh build of Windows.

DirectSound development was led by Frank Yerrace, a cheerful, mild-mannered hippie with coding skills we all respected. DirectInput was being single-handedly specified, implemented, and documented by Raymond Chen, one of the best developers at Microsoft and who had a particular passion for finding and fixing compatibility bugs in Windows. Raymond kept a piano in his office and always wore a suit, belying Microsoft’s famously dressed-down culture. He could type so fast that the cursor would just blur across the screen, and he was a huge fan of the Eudora email client for Windows. So much so, in fact, that every time a change to Windows broke the Eudora client, Raymond would stop all work until he’d personally fixed the issue.

The Direct3D team, acquired by Microsoft via a game engine company called RenderMorphics, was still based in London. Besides contributing six or so developers, they’d referred Colin McCartney to Microsoft, reportedly because they were reluctant to relocate away from London. RenderMorphics was led by former CEO Servan Keondjian, and his lieutenants Doug Rabson and Steve Lacey served as leads for a handful of other developers who were responsible for building the Direct3D APIs, especially the highly optimized software rasterizers that game developers of the early- to mid-1990s believed to be their stock in trade. Another RenderMorphics employee, Kate Seekings, had served as CEO before joining Microsoft as a program manager.

After a few months on the DirectX team, we got more reqs and I talked Eric into hiring most of the Softimage porting team: Chas Boyd, Xueping Deng, Anuj Gosalia, Steve Coy, and QA engineers Martin Lodge, Rich Dalton, and Sean Edmison. I heard some second-hand grumblings about pushback from the Advanced Consumer Technology division they were transferring from, but the transfers went through. My Softimage porting friends started working on libraries to layer on top of Direct3D and its “retained mode” API.

Windows’s 3-year ship cycle wasn’t fast enough to stay current with games, and because game developers didn’t want their products tied to the latest version of Windows, we had to make sure DirectX worked on the installed base of Windows 95 compatible computers. As a consequence, Eric negotiated with his management in the Windows organization to ship “outside the box”: not on the Windows 98 CD, but on interim ship vehicles. Microsoft then licensed the DirectX binaries to game developers, authorizing them to redistribute the DirectX binaries and installation package, and showed them how to kick off the DirectX installer if someone was trying to install their game on a machine that did not have the version of DirectX that the game needed to run. Because software – especially operating system software – is prone to developing complicated interdependencies between components that seem otherwise unrelated, it was a big deal for Windows management to agree to let Eric ship outside the box. But one consequence of this decision was that the DirectX ship schedule was brutal. We had to design, implement, and test not just new interfaces, which involved writing tests that adequately covered their functionality, but also sample programs that showed developers how to use the new features – all on a ship schedule that was 3x more compressed than the broader Windows organization. Oh, and our stuff had to be fully specified and robust for whichever version of Windows aligned with the most appropriate DirectX version.

---

Once I started with the Direct3D team, I began working on my first assignment: building drivers for 3D graphics hardware – a level closer to the hardware than the Softimage port, where we were using the OpenGL API that abstracted hardware. I made the driver for the S3 ViRGE my special project, knowing that S3’s 765 chip was a highly successful 2D accelerator that had sold dozens of millions of units because it delivered decent performance at a good price. S3’s driver code wasn’t great – validating Craig and Eric’s dim view of driver developers – but it also was only about 12,000 lines of code and proved easy to refactor¹. I ripped out thousands of lines of superfluous code and streamlined the driver to be Direct3D-specific.

Early in my tenure as Direct3D driver developer, I learned that Direct3D had a problem: on the one hand, with 3D hardware so new to the Windows platform, Direct3D was the first DirectX API that presented an opportunity to innovate; but the “innovative” API that Microsoft shipped in DirectX 2.0 and 3.0 was unusably bad, and unnecessarily so. I wasn’t on the Direct3D team when they’d designed the notorious Execute Buffer API – I know Eric offered it unwavering support, and the RenderMorphics developers obviously were big fans, since it was their invention. But building software that exposes hardware capabilities has to be done carefully, and although Execute Buffers were designed to anticipate hardware innovations in the industry, they presented an awkward programming model for developers, with too many lines of code needed just to draw one triangle. The RenderMorphics team had designed the API thinking that hardware vendors would eventually build chips that could natively run Execute Buffers; but the problem was, Execute Buffers weren’t an abstraction that any reasonable hardware designer would build into their product.

The graphics API we’d used for the Softimage port, OpenGL, had been designed primarily by graphics workstation vendors, and workstation applications did not have the same design constraints as games. For example, workstation applications placed a high priority on drawing 3D lines, while games relied on textures – 2D images that could be sampled into triangles to make games look as realistic as possible. Texturing was supported in OpenGL, though, and OpenGL was easier to use than Direct3D 2.0 and 3.0. With encouragement from graphics vendors (and Microsoft’s OpenGL team), game developers began asking Microsoft to consider killing Direct3D and replacing it with OpenGL.