Early Direct3D, COM and OpenGL
A friend was asking me recently about John Carmacks 1996 blog post endorsing OpenGL over Direct3D. Carmack’s post on this subject was a big event in Direct3D and OpenGL’s history because of course John Carmack was a legend in the game industry and DirectX has originally specifically been designed to support DOOM on Windows. I made the deal with John to have Microsoft port DOOM to Windows on the condition that IF he was satisfied with the quality of the port he would publish it as an Id title. My first attempt to port DOOM to Windows 3.1 was a failure. Windows just couldn’t do it, which led to the creation of DirectX in Windows 95 to make porting DOOM possible. DOOM was the first DirectX game. Obviously we consulted closely with Carmack on our plans to try to support 3D hardware in Windows 95 which was why it came as a huge shock to the DirectX team in 1996 when Carmack posted the following on his blog.
The effort to create the Direct3D API was initiated when the Windows NT team who had gotten a license from SGI for OpenGL refused to let us ship it with Windows 95. The OpenGL driver model that the Windows NT was designing for OpenGL at the time was also very primitive, it supported only very low level polygon rasterization hardware. Most 3D hardware available for the PC at that time actually decelerated 3D rendering performance as a consequence. Since the OpenGL team refused to work with us on OpenGL support for Windows 95, we acquired Rendermorphics and created our own 3D driver model for Windows 95 called Direct3D. It was designed at the outset to support the entire range of possible hardware acceleration that we hoped would become prevalent in the market from low-level rasterization all the way up the graphics pipeline to floating point transformation and lighting. At the time it was a much more advanced driver model for 3D acceleration than anything the Windows NT team was contemplating supporting for Windows NT. Carmacks principal stated objection to Direct3D in his post was as follows;
“The overriding reason why GL is so much better than D3D has to do with ease of use. GL is easy to use and fun to experiment with. D3D is not (ahem). You can make sample GL programs with a single page of code. I think D3D has managed to make the worst possible interface choice at every oportunity. COM. Expandable structs passed to functions. Execute buffers. Some of these choices were made so that the API would be able to gracefully expand in the future, but who cares about having an API that can grow if you have forced it to be painful to use now and forever after? Many things that are a single line of GL code require half a page of D3D code to allocate a structure, set a size, fill something in, call a COM routine, then extract the result.”
COM… short for Common Object Model was a major strategic push for Microsoft at that time. We had no official charter to create DirectX at that time, we just did it, but because the DirectX team was a “skunk works project” within the Windows 95 Operating System group where COM support was a major push, we felt strong internal pressure to adopt it in order to have a hope that DirectX might be embraced by Microsoft as a standard API in the future. If it was NOT COM enabled, the chances of its survival seemed remote. We weren’t happy about having to COMify DirectX but felt we had little choice. COM was a convoluted API that was understandably difficult for developers to adopt but it did have a very important property for DirectX… it enabled DirectX API’s to evolve very rapidly without having to worry about backwards compatibility with previous versions of the API. We knew that whatever we did in 3D at that time was going to be “wrong” and need rapid revision because the consumer market for 3D was so new, nobody had any idea how it would take shape. We designed Direct3D as a very low level API that OpenGL ( a high level API ) could sit on top of, again with the hope that eventually we would get support for OpenGL internally. As the first Direct3D documentation posted here shows, OpenGL support was built into the early Direct3D design plan… long before it ever became an issue of public contention.
Linked here is the very first Direct3D API documentation.
“The Direct3D HAL is tightly integrated with the DirectDraw HAL and the GDI display driver, giving hardware manufacturers a single, consistent interface to Microsoft graphics APIs, and a long-term, unified driver model for accelerated 3D. Hardware manufacturers need to write only a single driver to accelerate Direct3D, DirectDraw, GDI, and OpenGL. Hardware can accelerate all or part of the 3D graphics rendering pipeline, including geometry transformations, 3D clipping and lighting, and rasterization. The Direct3D HAL has been designed to accommodate future graphics accelerators in addition to those available today.”
Early arguments over Direct3D vs OpenGL were baffling because OpenGL IS NOT a driver model for Windows, it’s a high level 3D API. OpenGL provides no mechanism for hardware acceleration, a driver model for it ALWAYS has to be a proprietary OS solution. Direct3D was the Windows driver model for OpenGL hardware acceleration… nothing to fight about right? Direct3D provided the mechanism for the OpenGL API to interoperate and share graphics processing resources with the rest of the Windows GUI. So what was Carmacks beef?
1) No OpenGL API for Window 95, Microsoft’s CONSUMER OS version because the Windows NT guys refused to support Windows 95.
2) Absent the high level API support for OpenGL Carmack had to evaluate using the low-level Direct3D driver API directly… which was COM enabled to co-exist with all Windows API’s.
Of course it was a PITA to write a game to a low-level driver API designed to support a wide range of then non-existent 3D hardware, and COM was a PITA to adopt if you were just trying to crank out a game and ship it. But as troublesome as COM was, it played an important role in the ultimate success of DirectX. COM provided a way for the API to evolve with rapid releases of new versions of the DirectX API without BREAKING the previous versions of DirectX and the games that depended on it. If Carmack had adopted Direct3D for Quake, his game would have run without modifications on DirectX 2 through to DirectX 9 all the way to Windows XP because every subsequent generation of DirectX which often included radical API changes from its predecessor would have recognized Quake as a DirectX 2 game and exposed only DirectX 2 API’s for it to use while newer games could use very different DirectX 9 API’s on new Windows OS’s without conflict. The COM architecture ensured that game developers who targeted DirectX could ship a game and forget about it, reaping profits from its sales years later even as the OS technology evolved rapidly and incompatibly with older games. This FEATURE of DirectX gave games that used it tremendous longevity without requiring constant maintenance at the expense of more work initially. That tradeoff wasn’t ideal but also was not without its advantages. The need for constant backwards compatibility hamstrung the evolution of open API’s like OpenGL that had to try to maintain backwards compatibility over generations at the expense of innovation which is why OpenGL support remains such a scattered and inconsistently supported API across platforms and devices to this day.
What people who like to constantly gripe about Direct3D vs OpenGL today constantly fail to recognize is that Direct3D is the ONLY driver model for 3D hardware acceleration on Windows to this day… even for OpenGL based games! There are ZERO OpenGL games on Windows that don’t run on Direct3D drivers to get their hardware acceleration. 3D chip vendors like AMD and NVIDIA simply bolt OpenGL API bindings onto their Windows Direct3D drivers to support it. The consumer problem with applications that do this is that Microsoft does not provide OpenGL API compliance tests for these bindings which means they ship UN-TESTED for compatibility with Windows. Microsoft doesn’t ship untested drivers for Windows so these bindings are disabled by default unless consumers go to their 3D chip vendors and manually install them resulting in many OpenGL driver related support problems that the Windows WHQL driver certification tests were designed to prevent.
Apple’s recent announcement of a low-level 3D driver API called Metal is their acknowledgment of the need to expose more DIRECT access to 3D hardware acceleration to allow games and high level APIs to evolve faster and take more advantage of recent leaps in GPU performance without being hamstrung by the backwards compatibility constraints of a high level API like OpenGL that DOESN’T have a COM like model for handling API versioning. In essence Apple is recognizing that they need to embrace a Direct3D like API model for the same reasons DirectX did 15 years ago. To enable rapid evolution in 3D hardware support. Even John Carmack recognized this benefit to Direct3D’s design years later.
“id Software mad scientist and first-person shooter “granddaddy” John Carmack said that DirectX has matured to the point where it’s now a better API than OpenGL. It handles multi-threading better and newer versions manage state better. But he doesn’t have plans in moving to DirectX any time soon, blaming inertia for the studio’s continued use of OpenGL.”
So the understandable conflict over Direct3D vs OpenGL in its early days can be chalked up to a period in history of great uncertainty and rapid change that Direct3D anticipated and was designed to adapt to despite its many early shortcomings. Carmack, at the time was a Linux fan and held no love for Microsoft (understandably) so his views were certainly shaped by a desire NOT to have his games tied to a specific proprietary platform, nor was he thrilled to have Microsoft assert total control of the PC platform. Our primary goal in creating DirectX was to ensure that Microsoft’s dominion over the PC desktop didn’t put id Software out of business. Years later his views about Microsoft’s hegemony over the desktop have proven well founded as Microsoft has often casually made sweeping and destructive changes to the Windows gaming ecosystem in their desire to control more of it for themselves and the XBOX.
Although I was certainly a “company man” during my career at Microsoft I have suffered many of the same indignities at the hands of capricious technology changes Microsoft has made to Windows gaming over the years in my subsequent ventures. Here are just a few of my more recent Microsoft stories on the subject for another day.