Direct3D vs OpenGL
The Direct3D vs OpenGL debate which appears to have raged down the years since it started in 1996 began as follows…
The first generation of DirectX was little more than a library of hacks to the Windows 95 OS that overcame major limitations to gaming functionality. DirectX, like WinG, was never actually part of a major Microsoft OS release until Windows 98 actually shipped DirectX 6.0. (Vista was the first Windows OS to actually start replacing GDI with DirectX functionality) The first generations of DirectX where shipped as libraries with the games that used it. The API was called DirectX because most of the functionality was just API’s that bypassed bloated Windows API’s to enable low level access to hardware and/or driver functionality. The first DirectX API’s that shipped were DirectInput, DirectDraw, DirectSound and DirectPlay.
The early DirectX team was a loosely knit group led by Eric Engstrom and Craig Eisler in the Windows 95 media team, I had a team of contractors working on it in Developer Relations and we had other folks helping us out across the company. There are a lot of great stories about this period that I’ll try to get around to telling but the short of it was that DirectX was a huge hit right out of the gates. I don’t think it would be an exaggeration to claim that it made Windows 95 the consumer hit that it was on the backs of dozens of great games. Of the top 10 selling Windows 95 applications when Windows 95 shipped, 6 of them were DirectX games… Doom II for Windows was #1. The war over 3D started when it became clear that the next generation of DirectX would need a 3D API. There was no video driver architecture in Windows 95 for 3D. OpenGL was a 3D API but NOT a 3D driver architecture for graphics cards. There was no OpenGL driver standard for Windows. Although I had a 3D graphics background none of us really had any idea what a 3D driver API and driver model for consumer gaming hardware should look like. Clearly $200 3D video cards for games were going to look very different from $3000 OpenGL cards for CAD rendering. Fortunately a competing OS group at Microsoft, the Windows NT team, had licensed OpenGL from SGI for use in Windows NT. At the time there was a pretty active rivalry between Windows NT and Windows 95. It was widely agreed at Microsoft that as soon as Windows 95 shipped that would be the end of the Windows code base and all subsequent Windows consumer OS’s would be based on the newer 32bit Windows NT platform. (This didn’t actually happen until 5 years later in Windows 2000) Consequently the Windows NT team regarded any investment in Windows 95 features as redundant and competitive to their own efforts. When Eric Engstrom approached the NT team about providing us with an OpenGL library to add 3D support to DirectX 2.0 we were turned down. The Windows NT team did not want Windows 95 to be competitive with Windows NT for professional graphics.
The problem started when we didn’t take “no” for an answer. PC game developers at the time had no experience with hardware accelerated 3D or any established view about how they expected to take advantage of it from their DOS games. Microsoft had done the port of DOOM II for Windows for Id so even John Carmack had not developed an expressed opinion about it at the time. DirectX wasn’t about API’s it was about direct access to driver level hardware functionality for games, but in the case of 3D there was no Windows driver model at all for 3D for us to access. So we went to the highly esteemed graphics legend at Microsoft, Mike Abrash, who had been chartered with the task of specifying a 3D driver architecture for Windows NT called 3DDDI. Of course Abrash was defining 3DDDI with the expectation that OpenGL would be the API layered on top of it on Windows NT. Abrash… by sheer coincidence… had also been the guy who recruited Chris Hecker into Microsoft. Hecker had worked for Abrash briefly before joining the Advanced Technology Group and starting his own WinG project. We told Abrash that we wanted to implement his 3DDDI driver model for Windows 95.
Unlike OpenGL 3DDDI was just a document specifying driver level API’s that had to be implemented by somebody to work. Then we told our management that we wanted to buy a 3D game engine company to get a team of people experienced and focused on making 3D hardware accelerated games to implement an API just for games on top of 3DDDI. By positioning the effort as dedicated to just games, it couldn’t possibly threaten NT’s planned supremacy in the OpenGL based professional graphics market. Paul Maritz, the Microsoft senior executive then responsible for both the Windows 95 and Windows NT initiatives said that he would only support the effort IF Mike Abrash approved. For the history books, Mike was a great and brilliant guy, but from our point of view at that time he was also an obstacle and we were very “aggressive” about persuading him. I was charged with the task of identifying the company that Microsoft would acquire after Mike “agreed”.
Criterion a UK based 3D company, Argonaut, another UK based 3D company, Epic (famed for the Unreal Engine) and Rendermorphics also a UK company made my short list. I favored the UK companies because in my experience the British engineers were much more advanced in their knowledge of 3D graphics, software rendering and mathematics. Epic founder, Tim Sweeney was clearly off the charts brilliant but he was one genius and we needed a team of them. Eric Engstrom led negotiations to acquire Rendermorphics, a team of eight brilliant 3D engineers and relocated them to Redmond. Redermorphics President, Kate Seekings, came to work for me in Developer Relations to promote the new Direct3D API to developers and we hired Phil Taylor to be our resident 3D genius liaison to the developer community.
However our “aggressive pursuit” of getting 3D support into Windows 95 did not come without some painful consequences and a lot of bruised egos. The wild success of Windows 95 and DirectX 1.0 did not go without notice during this process and the previously stand-offish Windows NT team suddenly developed an interest in supporting games… They became threatened by the idea that we were going to make up our own 3D API and effectively stick them with supporting it! Furthermore we had effectively usurped control of the 3D driver architecture by having a more immediate and popular market need for it. SGI, their former competitive nemesis and raison d’être, was conveniently going out of business leaving their efforts increasingly irrelevant. Abrash left Microsoft shortly after the acquisition of Rendermorphics and joined… Id software. Chris Hecker also left Microsoft to become an “independent game developer” where he marshaled game developer support and media attention for OpenGL starting with John Carmacks public endorsement for OpenGL in an open letter to Microsoft written by Chris Hecker.
15 years later I can confess to a dirty secret that I could never share at the time. Eric, Craig and I all came from a “strategy” arm of Microsoft. We didn’t CARE which API won, for us just picking the fight was winning because consumer 3D support for games had become a central priority for Microsoft instead of a distant afterthought. If the consequence of really pissing off the NT group was them “teaching us a lesson” about how best to support 3D gaming on Windows… great! That was an improvement over “No”… remember DirectX was about drivers not about API’s, we didn’t care which API won as long as we created a consumer market for 3D hardware on the PC and clearly the OpenGL team needed a little competition to find their motivation. We also didn’t care which Windows 3D API PC game developers wanted to adopt… as long as they were adopting something on Windows… It was control of drivers on the PC that truly anchored Microsoft’s hegemony over the PC market not the bloated API’s developers had to use to reach the desperate array of incompatible hardware that Microsoft’s drivers unified.
My real reason for concern about OpenGL however was the ghost of WinG and the Disney Lion King disaster. I was going to be doomed to repeat that nightmare for hundreds of Windows 3D games if I didn’t get strong controls and standards in place quickly for consumer 3D drivers. Thanks to the Direct3D vs OpenGL war within Microsoft, consumer support for 3D hardware would exist in the Windows platform… but would they work with video card makers like 3DFX, ATI and Nvidia being forced to split their already challenged driver development efforts between several different 3D driver architectures? WinG and the Disney Lion King disaster was like the ghost of Marley haunting me every Christmas for the sin of creating a market for crappy video drivers that broke games.
Reproduced here for the first time is a thread from one of my last email exchanges with Bill Gates on the subject of broken video drivers sent 24 hours before I was terminated. The good news was that after my unceremonious departure, most of these recommendations were implemented. Elizabeth Wiewall who had worked for me in Developer Relations moved to a team that started what is now Windows Update… originally created to keep DirectX drivers current…
_____________________________________________
From: Alex St. John
Sent: Sunday, June 15, 1997 7:36 PM
To: Bill Gates; Pete Higgins; Paul Maritz; Deborah Black; Kevin Dallas; Jay Torborg; Eric Engstrom
Subject: FW: DirectX: The Party Pooper (PC Magazine)
This is our daily headache with making the PC a viable consumer entertainment device. It overshadows every technology we introduce in this space. We have superior multimedia technology to everybody now, we just can’t make it work reliably. The unfortunate thing about drivers is that they are not glamorous or exciting technology, and they exist at the junction between us, an OEM, and an IHV. When they blow up, everybody points at each other, and the media assumes Microsoft is the cause. They are also some of our most powerful platform IP.
If we are serious about being the leading consumer platform, we need to get serious about being a stable platform. That means making quality driver development, performance, installation, upgrade, and certification a religion. Our current standard is way to low. I believe we should have a driver compliance, and benchmark suite that we make pubic so that the market and the media can measure and judge these things independently. Compliance and performance self testing should be a feature of our OS’s. When a driver is bad we should be the first to know and be able to direct the user to a solution. If we don’t, we get blamed. I believe a proper driver conformance/performance suite would be a powerful tool for improving stability, by making the standard crystal clear for everyone, and by focusing attention on the transgressors who ship busted or uncertified drivers.
———-
From: Mark Kenworthy
Sent: Sunday, June 15, 1997 11:19 AM
To: Craig Eisler; Jason White; Morris Beton MM – Games
Cc: Eric Engstrom; Jay Torborg
Subject: RE: DirectX: The Party Pooper (PC Magazine)
And replacing one uncertified Creative driver with another uncertified Creative driver fixed a lot of the problems, but still left several audio problems. I guess slamming Creative doesn’t sell magazines.
—–Original Message—–
From: Craig Eisler
Sent: Saturday, June 14, 1997 2:32 PM
To: Jason White; Morris Beton MM – Games
Cc: Eric Engstrom; Mark Kenworthy; Jay Torborg
Subject: RE: DirectX: The Party Pooper (PC Magazine)
Anyhow, back to the install. Rebel Assault II worked fine. X-Wing vs.
TIE Fighter froze a short way into the program. Magic: The Gathering
died messily, after insisting that we reduce the screen resolution to
640-by-480 and 256 colors. Hellbender worked okay, but then the joystick
started losing its calibration. We reinstalled it a couple of times. But
even when we shut Win 95 down properly and restarted the machine, it
said we hadn’t, and performed a scandisk before rebooting. And we
rebooted a lot. We uninstalled everything but Rebel Assault, hoping to
get back to a workable system–to no avail.
Not what I would have expected as complaints. Not a single issue here is DirectX related. I would have expected to be beaten up about display drivers not working, machines dying after DirectX installed, the usual complaint when there is a complaint. The poor bastard had a Matrox card – its amazing his machine boots.
Instead, DirectX has become responsible for bad joystick drivers, OSR 2, and buggy games. Pretty cool that people think it is everything plus the kitchen sink. If only everything plus the kitchen sink always worked.
—–Original Message—–
From: Jason White
Sent: Friday, June 13, 1997 2:29 PM
To: Morris Beton MM – Games
Cc: Eric Engstrom; Craig Eisler; Mark Kenworthy; Jay Torborg
Subject: FW: DirectX: The Party Pooper (PC Magazine)
FYI
I won’t go into the sorry history of DirectX or recount how many
fourth-quarter seasons were missed as game developers labored with
drivers that shipped late, broken, or not at all. Today we’re up to
Version 3.0, and Microsoft is running true to form in that this is the
first generally satisfactory version.
—–Original Message—–
From: Dawn Zeh
Sent: Friday, June 13, 1997 11:23 AM
To: Internet Client and Developer News
Subject: DirectX: The Party Pooper (PC Magazine)
Summary: PC Magazine’s Bill Machrone writes about his family’s experiences with DirectX,
Microsoft’s application programming interface for gamers. DirectX solves a major problem for the programmers: the slowness and general unsuitability of the standard Windows APIs for gaming. It also ensures that Microsoft maintains control over the APIs. Machrone says that Microsoft is running true to form in that this is the first generally satisfactory version.
News from your Library –
DirectX: The Party Pooper (PC Magazine)
From PC Magazine for July 1, 1997 by Bill Machrone
Don’t ask my wife about DirectX. She has no idea what it is, but she hates it. With a passion. Don’t ask my son about DirectX. You’ll get a litany of complaints about drivers, certification, and interactions, delivered with all the moral outrage a 12-year-old can muster. And my daughter has no opinion on the matter. As long as she can chat with her friends online, she’s happy.
It all started with Andrew’s impending birthday. He’s mad for video games, and the choice was to get several games for the PC or a Nintendo64. We discussed the issue with him, and after careful consideration, he decided that he’d get more mileage and enjoyment from the PC route–given the opportunity to play multiplayer games over the Internet, the deeper play of the PC games, and the profusion of titles. As much as he’d love to play 3D Mario, the attraction of Rebel Assault II, X-Wing vs. TIE Fighter, and Magic: The Gathering was just too great.
Our latest computer promised to be a dynamite gaming machine: a 233-MHz AMD K6 with 64MB of RAM, a Matrox Millennium, a 4GB SCSI hard disk, a Sound Blaster 64, and a 12X CD-ROM. I’d already decided to upgrade the sub-$25 joystick to a Microsoft Sidewinder 3D Pro. We were looking forward to the greater stability afforded by the 3D Pro’s digital technology, not to mention the cool twisting, rudder, and strafing maneuvers. (I’m not much of a gamer, so I take Andrew’s word for all this.)
Joystick installation went smoothly, so we moved on to the stack of games. The 3D Pro came with a game called Hellbender, which Andrew says is just like Terminal Velocity, except where it’s different. We installed Rebel Assault II first, which then installed the DirectX drivers. DirectX, in case you’re as game-impaired as I am, is Microsoft’s application programming interface for gamers. It creates a thin, fast, consistent layer over the hardware, so programmers need write only to DirectX instead of supporting all the hardware configurations possible in a PC.
DirectX also solves a major problem for the programmers: the slowness and general unsuitability of the standard Windows APIs for gaming. It also ensures that Microsoft maintains control over the APIs. (Microsoft hates it when anybody else creates an API for Windows.) Programmers were going around Windows entirely, creating their own internal APIs for their games.
I won’t go into the sorry history of DirectX or recount how many fourth-quarter seasons were missed as game developers labored with drivers that shipped late, broken, or not at all. Today we’re up to Version 3.0, and Microsoft is running true to form in that this is the first generally satisfactory version.
Anyhow, back to the install. Rebel Assault II worked fine. X-Wing vs.TIE Fighter froze a short way into the program. Magic: The Gathering died messily, after insisting that we reduce the screen resolution to 640-by-480 and 256 colors. Hellbender worked okay, but then the joystick started losing its calibration. We reinstalled it a couple of times. But even when we shut Win 95 down properly and restarted the machine, it said we hadn’t, and performed a scandisk before rebooting. And we rebooted a lot. We uninstalled everything but Rebel Assault, hoping to get back to a workable system–to no avail.
Twelve-year-olds can be tough, but mine was close to tears. He was disheartened and stomped off to his room to read a nice, dependable book, which doesn’t need an operating system. Sharon was fuming, ready to take everything back to the store and trade it in for a Nintendo 64.
I figured that the best way to restore peace was to dig into the system and figure out what was wrong. I soon determined that of the eight or so registered DirectX drivers, one of the audio drivers was not certified. I knew that Creative Labs, the makers of the Sound Blaster, had been tardy in getting the latest drivers out, so I went to the company’s Web site and installed a new driver that had been posted just three days before.
Andrew started reinstalling everything, breathing a big sigh of relief each time we passed a previous crash point. Everything worked, with the only residual weirdness being that when you play Hellbender after having played X-Wing vs. TIE Fighter, it plays the Star Wars background music instead of its own. Win 95 still thinks that it’s been crashed from time to time, and some of my MIDI programs are acting strangely, but we’re making progress.
ZWviaNewsEDGE
Copyright (c) 1997 Ziff Desktop Information
Received by NewsEDGE/LAN: 6/12/97 3:05 PM



Hi Alex! Thank you for the mention… working for you in as a DirectX games evangelist was definitely one of the most fun gigs I have had in my career 😉 Cheers!!
Thanks for the kind words Alex. DirectX evangelism was and is one of the high points of my career. It wasn’t the same after you got fired :-).
You know you have to talk about the spaceship right?.
Oh yes.. I’m getting to it Phil.
Phil Taylor the legendary cranky Direct3D evangelist ladies and gentlemen! Here’s a classic Phil email I like to call “SHUT UP, IT’s working already no thanks to YOU Morons!”
_____________________________________________
From: Philip Taylor
Sent: Monday, June 16, 1997 11:24 AM
To: Ty Graham; Nicholas Wilt; Charles Boyd; Steve Smith (DRG, Redmond)
Cc: Scott Leatham; Morris Beton; Tod Nielsen; Mark Kenworthy; Jay Torborg; Deborah Black; Moshe Dunie; Kevin Dallas; Kevin Bachus
Subject: RE: Unreal status
We are there.
Unreal runs on D3D.
Mark Rein, the marketing guy, looked at it and said it was good enough to show, since even at that early stage “it doesnt suck”.
Tim felt it was far enough that with another day he would have it showable for E3. Tim paid me 2 further complements:
“thats not much code”
“thats about how long it took me to get Glide to that point”
So in terms of how much code and how long it takes to code it up – DrawPrim has really pulled its weight.
I have just done a post-analysis on the code ( good thing, I found a bug I am emailing Tim about ) and the following details are significant:
it took ~30 hrs for the entire port
it look ~1000 lines of code.
This data needs to be public.
—
general analysis
1 source file,
4 global functions
2 classes
texture class
render class
total file size 1740 lines, containing
**224 lines blank
**502 lines comments,
**1014 lines of source
—
further broken down as:
*49 lines public defs
*227 lines in texture class
*694 lines in render class
*44 unreal callback
**1014 total
—
total time expended:
wed – 3 hrs
ddraw/d3d init and term
th – 14 hrs
adding z-buffer
basic poly drawing
basic texture cache manager
basic texturing ( textures treated as 16-bit, palettes ignored )
required on-the-fly conversion from Unreal textures to D3D textures
*5-6 hrs tracking down my own stupid DDraw bug.
fri – 15 hrs
moved to 8-bit palettized textures
required on-the-fly conversion from Unreal palettes to D3D palettes.
added mipmaps
tested on 9-level deep mips
added 2 pass texturing for lightmaps.
multiple blending modes, etc
total time-> 32 hrs
of which 6 hrs were due to a stupid coding error on my part
__
specific analysis
2 classes
class FD3DTexture
class FDirect3DRenderDevice : public FRenderDevice
—
6 lines of header includes
1 extern var
1 extern func
1 #undef
5 #defines,macros
11 globals
20 lines, stats type
4 lines, texcallback type
—
*49 total in defs
—
//
// The Direct3D Texture class.
//
class FD3DTexture
//
—
2 global dx functions
20 lines texenum callback
9 tex format chooser
—
10 lines 1 global unreal function, on-the-fly unreal palette to ddraw palette conversion
—
24 lines d3dtexclass class def
—
164 lines, d3dtexclass impl
56 lines, d3dtexclass initempty
creates single texture
sysmem/vidmem pair
64 lines, d3dtexclass initemptymip
sysmem/vidmem pair for each
creates mipmap chain, n deep
36 lines, d3dtexclass restore
does a load to get a valid texturehandle
8 lines, d3dtexclass release
releases all surfaces
—
29 enums
10 converter
24 class def
164 impl
—
*227 total in texture area
—
//
// The Direct3D rendering device.
//
class FDirect3DRenderDevice : public FRenderDevice
//
—
1 global dx functions
12 lines, devenum
—
56 lines d3dtexclass class def
—
173 lines d3drenderdev impl
private impl
17 lines, d3drenderdev init3dstate
set initial renderstates
44 lines, d3drenderdev init3d 61
create 3ddevice
create viewport
call init3dstate
41 lines, d3drenderdev ddinit 102
release buffers
56 lines, d3drenderdev ddsetmode
directdrawenumerate/directdrawcreate 158
setdisplaymode
create surfaces
call init3d
15 lines, d3drenderdev ddterm 173
release buffers
bug – no release of the zbuffer
add “RELEASE(ZBuffer);” after “RELEASE(FrontBuffer);”
—
173 private impl providing dd/d3d buffer,mode init,term
—
83 lines public interface
33 lines, d3drenderdev init3d
calls ddinit
16 lines, d3drenderdev exit3d
calls setcooperativelevel,switches back to unreal software renderer
calls ddterm
9 lines, d3drenderdev flush3d
calls unregistertexture to flush cache
16 lines, d3drenderdev lock3d
calls beginscene
9 lines, d3drenderdev unlock3d
—
83 unreal render,mode,frame init and term
client of above private impl
—
192 lines texture caching
27 lines, d3drenderdev buildtexture
performs unreal texture to d3d texture on-the-fly conversion
105 lines, d3drenderdev registertexture
if cache full, dump it –>needs to do true lru
registers with cache
create empty texture
lock it
use buildtexture to convert and spray bits
unlock it
restore to get valid texture handle
return handle
29 lines, d3drenderdev unregistertexture
unregisters with cache
17 lines, d3drenderdev locktexture 271
if in cache, makes sure handle is valid and returns it
if not in cache, adds it and gets the handle
14 lines, d3drenderdev unlocktexture 284
not needed
—
192 texture caching
—
181 lines poly drawing
2 #defines
4 globals
87 lines, d3drenderdev drawpolyv 372
double pass textured flat shaded backgrounds
first pass is normal texture phase
second pass is lightmap phase
perf issue, calculating vertex data twice, 2nd time is a waste!!!
4 globals
56 lines, d3drenderdev drawpolyc 426
single pass textured gouraud shaded characters
28 lines, d3drenderdev drawpolyf 454
—
10 defs
171 poly drawing
—
7 lines, d3drenderdev exec 461
—
7 lines exec
—
83 lines unreal interface
192 texture
10 defs
171 poly
7 exec
453 public impl
—
12 enum
56 class def
173 private impl
453 public impl
*694 total in render area
—
*44 lines, 1 global unreal callback
hows that sound?
given the right prior conditions:
a clean interface for me to plug into,
a good programmer to work with,
and no tricky alpha crap ( or time for me to get more learned on alpha tricks )
I can repeat this ad infinitum.
Who do you want ported next?
—–Original Message—–
From: Ty Graham
Sent: Monday, June 16, 1997 8:44 AM
To: Nicholas Wilt; Charles Boyd; Steve Smith (DRG, Redmond); Philip Taylor
Subject: Unreal status
I got the great “16 hour” mail last week. Very cool.
What’s happening now? What progress have we made since?