Direct 3D and OpenGL
by Paul Hsieh

Please note, that my employer does not endorse anything on this page.

What follows is a chronology of the significant events that have occurred in the development community with regards to the Direct 3D vs OpenGL war that has ensued. Microsoft on the side of Direct 3D, and a significant number of high profile game developers, as well as all of SGI on the side of OpenGL. As of this writing, the war has barely begun, but it is sure shaping up to be one huge black eye for Microsoft developer relations.

If you think I've missed something, or you think you have a piece of news about Direct 3D or OpenGL that is relevant to the war, please email it to me.

Here's some background that is missing in the chronology below that will help those unfamilliar with what has been happening:

Chapter 1 -- The War begins

John Carmack is the head programmer at id software, famous for bringing us, Wolf 3D, DOOM, Heretic, and Quake. On Tue Dec 17 1996, at 01:05 he wrote the following:

I am going to use this installment of my .plan file to get up on a soapbox about an important issue to me: 3D API. I get asked for my opinions about this often enough that it is time I just made a public statement. So here it is, my current position as of december '96...

While the rest of Id works on Quake 2, most of my effort is now focused on developing the next generation of game technology. This new generation of technology will be used by Id and other companies all the way through the year 2000, so there are some very important long term decisions to be made.

There are two viable contenders for low level 3D programming on win32: Direct-3D Immediate Mode, the new, designed for games API, and OpenGL, the workstation graphics API originally developed by SGI. They are both supported by microsoft, but D3D has been evangelized as the one true solution for games.

I have been using OpenGL for about six months now, and I have been very impressed by the design of the API, and especially it's ease of use. A month ago, I ported quake to OpenGL. It was an extremely pleasant experience. It didn't take long, the code was clean and simple, and it gave me a great testbed to rapidly try out new research ideas.

I started porting glquake to Direct-3D IM with the intent of learning the api and doing a fair comparison.

Well, I have learned enough about it. I'm not going to finish the port. I have better things to do with my time.

I am hoping that the vendors shipping second generation cards in the coming year can be convinced to support OpenGL. If this doesn't happen early on and there are capable cards that glquake does not run on, then I apologize, but I am taking a little stand in my little corner of the world with the hope of having some small influence on things that are going to effect us for many years to come.

Direct-3D IM is a horribly broken API. It inflicts great pain and suffering on the programmers using it, without returning any significant advantages. I don't think there is ANY market segment that D3D is apropriate for, OpenGL seems to work just fine for everything from quake to softimage. There is no good technical reason for the existance of D3D.

I'm sure D3D will suck less with each forthcoming version, but this is an oportunity to just bypass dragging the entire development community through the messy evolution of an ill-birthed API.

Best case: Microsoft integrates OpenGL with direct-x (probably calling it Direct-GL or something), ports D3D retained mode on top of GL, and tells everyone to forget they every heard of D3D immediate mode. Programmers have one good api, vendors have one driver to write, and the world is a better place.

To elaborate a bit:

"OpenGL" is either OpenGL 1.1 or OpenGL 1.0 with the common extensions. Raw OpenGL 1.0 has several holes in functionality.

"D3D" is Direct-3D Immediate Mode. D3D retained mode is a seperate issue. Retained mode has very valid reasons for existance. It is a good thing to have an api that lets you just load in model files and fly around without sweating the polygon details. Retained mode is going to be used by at least ten times as many programmers as immediate mode. On the other hand, the world class applications that really step to new levels are going to be done in an immediate mode graphics API. D3D-RM doesn't even really have to be tied to D3D-IM. It could be implemented to emit OpenGL code instead.

I don't particularly care about the software only implementations of either D3D or OpenGL. I haven't done serious research here, but I think D3D has a real edge, because it was originally designed for software rendering and much optimization effort has been focused there. COSMO GL is attempting to compete there, but I feel the effort is misguided. Software rasterizers will still exist to support the lowest common denominator, but soon all game development will be targeted at hardware rasterization, so that's where effort should be focused.

The primary importance of a 3D API to game developers is as an interface to the wide variety of 3D hardware that is emerging. If there was one compatable line of hardware that did what we wanted and covered 90+ percent of the target market, I wouldn't even want a 3D API for production use, I would be writing straight to the metal, just like I allways have with pure software schemes. I would still want a 3D API for research and tool development, but it wouldn't matter if it wasn't a mainstream solution.

Because I am expecting the 3D accelerator market to be fairly fragmented for the forseeable future, I need an API to write to, with individual drivers for each brand of hardware. OpenGL has been maturing in the workstation market for many years now, allways with a hardware focus. We have exisiting proof that it scales just great from a $300 permedia card all the way to a $250,000 loaded infinite reality system.

All of the game oriented PC 3D hardware basically came into existance in the last year. Because of the frantic nature of the PC world, we may be getting stuck with a first guess API and driver model which isn't all that good.

The things that matter with an API are: functionality, performance, driver coverage, and ease of use.

Both APIs cover the important functionality. There shouldn't be any real argument about that. GL supports some additional esoteric features that I am unlikely to use (or are unlikely to be supported by hardware -- same effect). D3D actually has a couple nice features that I would like to see moved to GL (specular blend at each vertex, color key transparancy, and no clipping hints), which brings up the extensions issue. GL can be extended by the driver, but because D3D imposes a layer between the driver and the API, microsoft is the only one that can extend D3D.

My conclusion about performance is that there is not going to be any significant performance difference (< 10%) between properly written OpenGL and D3D drivers for several years at least. There are some arguments that gl will scale better to very high end hardware because it doesn't need to build any intermediate structures, but you could use tiny sub cache sized execute buffers in d3d and acheive reasonably similar results (or build complex hardware just to suit D3D -- ack!). There are also arguments from the other side that the vertex pools in d3d will save work on geometry bound applications, but you can do the same thing with vertex arrays in GL.

Currently, there are more drivers avaialble for D3D than OpenGL on the consumer level boards. I hope we can change this. A serious problem is that there are no D3D conformance tests, and the documentation is very poor, so the existing drivers aren't exactly uniform in their functionality. OpenGL has an established set of conformance tests, so there is no argument about exactly how things are supposed to work. OpenGL offers two levels of drivers that can be written: mini client drivers and installable client drivers. A MCD is a simple, robust exporting of hardware rasterization capabilities. An ICD is basically a full replacement for the API that lets hardware accelerate or extend any piece of GL without any overhead.

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.

Ease of use is damn important. If you can program something in half the time, you can ship earlier or explore more aproaches. A clean, readable coding interface also makes it easier to find / prevent bugs.

GL's interface is procedural: You perform operations by calling gl functions to pass vertex data and specify primitives.

        glBegin (GL_TRIANGLES);
        glVertex (0,0,0);
        glVertex (1,1,0);
        glVertex (2,0,0);
        glEnd ();

D3D's interface is by execute buffers: You build a structure containing vertex data and commands, and pass the entire thing with a single call. On the surface, this apears to be an efficiency improvement for D3D, because it gets rid of a lot of procedure call overhead. In reality, it is a gigantic pain-in-the-ass.

        (psuedo code, and incomplete)
        v = &buffer.vertexes[0];
        v->x = 0; v->y = 0; v->z = 0;
        v->x = 1; v->y = 1; v->z = 0;
        v->x = 2; v->y = 0; v->z = 0;
        c = &buffer.commands;
        c->operation = DRAW_TRIANGLE;
        c->vertexes[0] = 0;
        c->vertexes[1] = 1;
        c->vertexes[2] = 2;
        IssueExecuteBuffer (buffer);

If I included the complete code to actually lock, build, and issue an execute buffer here, you would think I was choosing some pathologically slanted case to make D3D look bad.

You wouldn't actually make an execute buffer with a single triangle in it, or your performance would be dreadfull. The idea is to build up a large batch of commands so that you pass lots of work to D3D with a single procedure call.

A problem with that is that the optimal definition of "large" and "lots" varies depending on what hardware you are using, but instead of leaving that up to the driver, the application programmer has to know what is best for every hardware situation.

You can cover some of the messy work with macros, but that brings its own set of problems. The only way I can see to make D3D generally usable is to create your own procedural interface that buffers commands up into one or more execute buffers and flushes when needed. But why bother, when there is this other nifty procedural API already there...

With OpenGL, you can get something working with simple, straightforward code, then if it is warranted, you can convert to display lists or vertex arrays for max performance (although the difference usually isn't that large). This is the right way of doing things -- like converting your crucial functions to assembly language after doing all your development in C.

With D3D, you have to do everything the painful way from the beginning. Like writing a complete program in assembly language, taking many times longer, missing chances for algorithmic improvements, etc. And then finding out it doesn't even go faster.

I am going to be programming with a 3D API every day for many years to come. I want something that helps me, rather than gets in my way.

John Carmack Id Software

The above message caused a "virtual" frenzy on the USENET newgroups and Most have sided with Carmack, but are wondering about the state of OpenGL for PCs. For those interested in programming in OpenGL for Windows 95, you can download it from Microsoft directly. Alternatively, you might want to look at which is now the home for SGI OpenGL for PCs (formerly COSMOGL).

Id software recently put their money where their mouths were and released a preliminary version of GLQuake.

Chapter 2 -- The Game Developer Community Speaks

You might think that a juggernaut like Microsoft can simply wait this one out until the OpenGL movement dies down while they continue to push their broken Direct3D standard, however recently a group of professional game developers got together to write an open letter to Microsoft:

We, the undersigned professional game developers, call on Microsoft to continue its active OpenGL development, to ship its DirectDraw bindings for OpenGL and the Windows95 MCD driver-enabled OpenGL, and to continue to improve its implementation of the OpenGL API and its driver models by aggressively supporting common extensions and future ARB-approved standard features. As developers, we believe the choice of which 3D API to support for our games should be ours alone.

We want any 3D API competition to happen on an open technical playing field, with us, the people who actually write the games, deciding which APIs we should and should not use. This open technical competition is healthy for the industry and will result in better games and 3D technology. We recognize Microsoft must take part in creating this technically competitive environment because of their control over the operating system, and we urge the company to be a positive force in doing so by actively supporting OpenGL. The entire PC game industry will benefit as a result.


Bill Baldwin        Brian Hook         William Scarboro
Sean Barrett        Andrew Howe        Jason Shankel
Ken Birdwell        Brent Iverson      Zachary Simpson
Seamus Blackley     Rick Johnson       David Stafford
Stefan Boberg       Dave Kaemmer       Tim Sweeney
John Carmack        Donavon Keithley   Chris Taylor
Glenn Corpes        Jason Leighton     Dave Taylor
Steve Crane         John Lemberger     Trey Taylor
Mark Dochterman     Peter Lincroft     Cameron Tofer
Jim Dose            Mike Linkovich     Matt Toschlog
James Fleming       Jonathan Mavor     Neall Verheyde
Rick Genter         Stan Melax         Charlie Wallace
Ed Goldman          John Miles         Kevin Wasserman
Chris Green         Doug Muir          Patrick Wilkinson
Robin Green         Casey Muratori     David Wu
Mike Harrington     John Nagle         Pat Wyatt
Ryan Haveson        Mike Newhall       Billy Zelsnack
Chris Hecker        Jay Patel          Greg Zeschuk
Lawrence Holland    John Romero

It remains to be seen whether or not Microsoft will listen. Unfortunately, the tone of the letter implies that Microsoft should take an interest in how developers outside of Microsoft should be assisted by work done inside Microsoft. For a reasonable company which seeks loyalty from those that support them, this should be no problem. But this is Microsoft we are talking about here. I suspect many of the signers above expect that Microsoft will not do anything to help them especially with respect to OpenGL, and their real underlying point was to help expose Microsoft for what they are.

In case you have any doubt, these are in fact some of the industry's top game programmers; I recognize about half of their names and can confirm that this is not some random list of obscure unknowns. This letter was authored by Chris Hecker, who writes for Game Developer magazine and a well known game programmer himself.

The story doesn't end here though. At about the same time as the above letter was sent off to Microsoft, the current Direct 3D Evangineer, Phil Taylor, at Microsoft had the audacity to invade the OpenGL game developer's mailing list to spout some propaganda about being able to port some application to their new Draw Primitive API in 32 hours. Of course, they are missing the point. The OpenGL community have other reasons besides some technical porting issues that Direct 3D insiders have an unfair advantage in performing.

Basically, Microsoft's name is mud in the game community until they are willing to show some humility, and cater to the needs of game programmers by providing an MCD for Windows 95 which binds to Direct Draw.

Microsoft recently has responded (after quite some time, and on the heels of letting Alex St. John go) by saying that they want to hold a developer's round table on 3D after MeltDown (a gathering for Windows hardware and software developers.) This is not exactly what developers were looking for. I believe and predict (07/12/97) Microsoft will use this opportunity to do everything it can to try to sway developer's opinions back from OpenGL (which are growing beyond Microsoft's control) to Direct 3D. As I posted on USENET, I have this theory that they will use the conference to announce Direct Draw bindings for OpenGL will be available soon as a method of quieting down the dissenting OpenGL voices, then spend the rest of the conference on Direct 3D propaganda. I will not be attending the conference, but I hope to get reports back to see how close my theory is.

Please note that the comments I make here are not necessarily in line with the feelings of those that signed the letter above. As a particular example, in public USENET news forums Glen Corpes has indicated, that while he is a strong supporter of Direct 3D, his motivation for wanting Microsoft to release the Open GL MCD for Windows 95 is so that there is fair competition among the 3D APIs.

Chapter 3 -- Brian Hook speaks

As is known by now, Brian Hook, the well known 3D evalangelist and implementor (formerly his own company, WK Software) has joined id software. He is uniquely qualified in his ability to compare Direct 3D with OpenGL as he has worked with both from a driver implementation layer as well as actually using both. He is currently working on porting Quake 2 to OpenGL on various PC platforms, and has been giving his progress reports in his .plan (finger to see.)

The following is an excerpt from Brian Hook's .plan file dated June 24, 1997.

Okay, first off, let's establish that OpenGL has its share of problems. These are growing pains. It's normal. Let us assume, for the sake of argument, that Direct3D and OpenGL on the PC are at roughly parallel points in their evolution.

Let us also assume that they have roughly the same amount of driver support committment from IHVs. Okay, big assumption, but bear with me.

What I am saying is assume that they are functionally equivalent, which is also a rather big assumption. If we do this, the question becomes very simple: why support one over the other?

Well, I'm sure you folks know by now that I think OpenGL is easier to use. I would daresay that most people agree. So that's a pretty big plus. OpenGL does have an extension mechanism, and this tangibly becomes important as I'll relate in a second. Finally, OpenGL is portable as hell, and this is cool.

As for extensions...

Let me put this in concrete terms -- without these extensions, some IHVs would be really really hurting when it comes to Quake2. And this isn't necessarily limited to the software we're doing -- other people will have similar issues arise that can easily be worked around if the vehicle is present.

For example, our particle systems are currently rendered with independent triangles, and this is a royal bitch on just about any system (and would be a performance hog on Direct3D also, so this isn't an OpenGL specific problem, but the solution IS specific to OpenGL). It would be really neat if we could, say, tell a driver to render a particle system that we define, and it just does The Right Thing -- i.e. whatever makes it give the right output and also gives the best performance for that hardware.

This is impossible to do with Direct3D.

This is possible with OpenGL.

Can you see where I'm taking you?

Okay, let's take another example -- multitexture. SGI has a nice proposal that I happen to like. We'd like to use it. SGI can hand that proposal to an IHV, and we get a turnaround of about 7 days. Now, I've heard rumors of a multitexture thing for Direct3D for almost a year now, but it isn't part of DX5, and when is DX6 going to ship?

Okay, so if we really need multitexture (which is very nice for our hardware rendering), we'd be screwed with Direct3D. Pure and simple.

Now you see why being dependent on Microsoft for shipping our products isn't a Good Idea. Particle systems and multiple texture maps are vital technologies to us, and if we were relying on Microsoft to push this stuff through, we'd be sitting on our asses this Christmas instead of shipping a game.

Are we getting the picture now? Are we understanding why OpenGL is just so damn nifty it's hard to ignore?

Okay, now let's move on to the subject of tools. All of our level editors and miscellaneous texture mapping tools are done with OpenGL. This allows us to edit and modify them quickly and, more importantly, allows us to run on NT. If we used Direct3D, we'd all be using Win95, and this is just not my idea of a good operating system for development. WinNT does NOT have Direct3D with hardware acceleration on it. That's a pretty big problem.

For tool development, OpenGL is vastly superior to Direct3D simply because of its ease of use and the plethora of high end workstations that support it. This ties into the theme of portability -- we can write a nice tool using OpenGL and with minimal hassle have it portable between SGI, Win32, and Linux. We license our tools and engines to select partners, and it's nice when we can tell them "Sure, you can use our stuff on any of these platforms." That's just plain cool from a technology standpoint.

In THEORY OpenGL is portable -- in practice, it has a ways to go simply because the drivers are flaky (just like D3D's). In THEORY Direct3D is NOT portable. This means tools and games we write that use Direct3D are NOT portable to other platforms, locking us into the world of Microsoft. I'm sure Bill loves this, but we and millions like us don't relish that thought.

And I'm not just talking portable tools. Quake2 is going to rock. Hard. It's an amazingly kick ass game, and I haven't felt this good about a product since I worked on Voodoo at 3Dfx, which is saying a lot.

And what I really love is that tens of thousands of people using SGI, Linux, and whatever else we find with OpenGL support will get hardware accelerated Quake2 support. If Apple supports OpenGL (which they really really should), then they would automagically get Quake2 on that system.

If we were using Direct3D, Quake2 would probably be available only on Win95. Hell, NT users wouldn't even get it. How sucky is that?

OpenGL allows us to deploy our software to as many varied platforms as possible with minimal hassle. This is fundamentally sound both in terms of business sense and in terms of pure technical coolness.

Please note that the above is only an excerpt and it does not include his various disclaimers about still leaving the option open to use Direct 3D, among other things.

If you have access to the UNIX finger command and are interested in OpenGL on the PC, I highly recommend you finger on a regular basis. He is chronicling his adventures with various hardware support stories and details there. His initial reports were that it was rough going, but as he has been progressing it appears as though Quake 2 and OpenGL in general are really starting to shape up for the PC.

Chapter 4 -- A second letter

Another Open letter, aimed at anyone who wanted to sign it, and in general more inclusive of amateur game programmers has been whipped up and has its own web page. Game programmers who were passed up on the first letter are encouraged to sign this one. Chris Hecker has posted on USENET to the effect that he would work to make sure this second letter also reached the right folks at Microsoft. (Though personally, I think this is of secondary importance, as the show of solidarity is what it is really about.)

Chapter 5 -- Intel frowns on Direct 3D

The following letter was posted on the Direct X mailing list. It was written by Mark Kilgard in response to an article in the EE Times written by some folks at Intel.

3D programmers,

The following article is a very interesting, though technical, criticism of Direct3D by graphics engineers at Intel. Check out:
The above EE Times article explains that when CPU-based 3D engines batch together vertex information so that all the information for a single vertex is in a single contiguous structure, this is in fact not optimal for current Intel microprocessors.

While the article does not directly mention Direct3D, the analysis is a clear criticism of Direct3D's vertex specification scheme. Intel's criticisms still apply even when DirectX 5's new DrawPrimitive interface is used! (By comparsion, as will be explained, OpenGL's vertex array mechanism is extremely well suited for precisely the vertex processing optimizations described by Intel's engineers in the article.)

First a bit of background about how Microsoft's Direct3D immediate mode specifies vertices. There are three (and only three) structures available in Direct3D to specify a vertex:

    D3DVERTEX, an untransformed and unlit vertex

    D3DLVERTEX, a lit but untransformed vertex
    D3DTLVERTEX, a transformed and lit vertex
The caret (^) marks show the slight letter differences between the three structures. Here's what each (simplified) Direct3D vertex structure looks like:
    typedef struct {
      float x, y, z;
      float nx, ny, nz;
      float tu, tv;
    } D3DVERTEX;

    typedef struct {
      float x, y, z;
      long reserved;
      long color, specular;  /* Byte packed! */
      float tu, tv;

    typedef struct {
      float x, y, z;
      float rhw;  /* Reciprocal of homogenous w. */
      long color, specular;  /* Byte packed! */
      float tu, tv;
You'll notice that each vertex structure is eactly 32 bytes long. You'll also notice that an array of any one of the three structures means that there will be a 20 byte gap between each set of X, Y, and Z coordinates. This gap is at the heart of Intel's complaint.

The vertex optimization described by Intel in the article is that instead of packing all of a vertex's information in a single structure, you can keep the position information separate from the lighting, surface normal, and texture coordinate information. The advantage to this approach is that vertices can be processed more cache-efficiently in CPU-pipelined stages.

To maximize the cache bandwidth and some pre-fetching capabilities of the Pentium and Pentium Pro processors, it is significantly better if each type of vertex information (positions, normals, colors, and texture coordinates) were kept in a distinct array. Then, the Pentium or PPro processor can more efficiently process each information type within a large array of vertices in a cache- and processor-efficient manner.

So what's the problem with Direct3D? Just that this optimization is completely impractical because of Direct3D's mandated structure formats that *require* all the vertex information be packed in one of its three structure formats. For example, if you processed the vertex positions in a single pass, you would be loading surface normal, texture coordinates, and/or color information into the cache which is not needed during that position transformation stage. For a long array of vertices, Direct3D's scheme can cause sub-optimal cache and sub-optimal processor pipelining.

How big a hit is Direct3D's vertex structure scheme? Intel estimates "that a simple change of data structures can result in a 25 percent improvement in performance" (quoting the Intel article).

Intel's optimization is quite simple. Just keep each array of vertex information (normals, positions, texture coordinates, and colors) in a distinct array so they can be processed in a more cache-efficient multi-pass manner. Read the article for the details.

OpenGL's vertex array facility is ideally suited for such an optimization and provides the necessary API today for an OpenGL implementation to incorporate Intel's optimization. Direct3D has no similiar way to incorporate the optimization without a total overhaul of Direct3D's vertex specification mechanism.

Here's how easy it is to specify separate arrays of vertex information in OpenGL with vertex arrays:

    #define NUM_VERTICES 4000

      GLfloat xyzs[NUM_VERTICES][3];
      GLubyte normals[NUM_VERTICES][3];
      GLshort texcoords[NUM_VERTICES][2];
      GLubyte colors[NUM_VERTICES][3];

      glVertexPointer(3, GL_FLOAT, 0, xyzs);
      glNormalPointer(3, GL_UNSIGNED_BYTE, 0, normals);
      glTexCoordPointer(3, GL_SHORT, 0, texcoords);
      glColorPointer(3, GL_UNSIGNED_BYTE, 0, colors);
This sets up OpenGL so that vertices from these distinct vertex arrays can be efficiently sent to OpenGL. Notice that each array is distinct in memory and all the various vertex information types are kept efficiently packed in these distinct arrays.

As a comparison, in Direct3D, keeping 4000 vertices in Direct3D's D3DVERTEX structure would require 128,000 (32*4000) bytes. The above specification for OpenGL uses a compact 84,000 (12*4000+3*4000+6*4000) bytes. Not only will the OpenGL vertex arrays be more cache-efficient to process, but they will also take less space overall. OpenGL (unlike Direct3D) gives programmers the flexibility to specify their vertex data using the data types that are computationally or spatially most efficient. That's a double win for OpenGL.

While the article never mentions OpenGL or Direct3D explicitly, it is clear that Direct3D is what the Intel engineers were critizing. When the article complains about inefficient vertex structure handling, the example used is described this way:

    "Assume that all data is single-precision floating-point (4 bytes),
    and that eight pieces of input data are needed (x, y, z position,
    x, y, z normal and u, v texture)."
This is precisely describing Direct3D's D3DVERTEX structure (check the C structure above). Hmm.

The format that vertices actually should be specified in mostly depends on the application and not merely on what vertex transformation method is most optimal (on a specialized 3D transformation engine, Intel's optimization is likely not relevant), but OpenGL is clearly the more flexible API when it comes to how and in what data types vertex information is presented to the API.

Intel is clearly evaluating the technical merits of both OpenGL and Direct3D. It is very prudent to take Intel's criticisms of Direct3D quite seriously. Intel is a founding member of the OpenGL Architectural Review Board, and it is widely known that Intel is actively working on OpenGL-oriented 3D acceleration hardware. If Intel begins putting OpenGL 3D acceleration hardware on motherboards (as I expect Intel to do), this could wind up being of tremendous importance to OpenGL software developers.

I won't comment on Mark's extrapolations, however as an experienced x86 programmer, I can confirm that this analysis is right on the money. The performance hit sounds about right to me. D3D is not just hard to use, its not just a lesser API than OpenGL, it not only has less functionality than OpenGL but it has also been designed in such a way that there are serious performance implications that can't be worked around. I believe the folks at 3DFX have noticed precisely this same thing some time ago which was their motivation for building GLide and for their current work on OpenGL drivers.

Chapter 6 -- Alex St. John leaves Microsoft

A recent C|net central article managed an interview with Alex St. John after he officially left Microsoft. It is definately an eye opener to get some perspective of the internal politics at Microsoft (which he is now free to reveal) from someone who was in the middle of it all.

He has definately cleared the air about why Microsoft wants D3D instead of OpenGL, and makes the good point about mixing multimedia with 3D. However, I (and I think a lot of other people, of course) do not agree with him about the appropriateness or abilities of OpenGL to be a 3D gaming API.

I think the "drivers suck" and other excuses he makes are just sour grapes but I'm glad that the fact that the substance of Microsoft driving D3D is highly politically based was brought to light. The damage this article has wrought will be hard for Microsoft to repair.

The article itself is laced with comments and opinions by the reporter which may destort exactly what was being said. While it doesn't look too twisted it does seem engineered to cause the maximum amount of damage to Microsoft and its credibility. BTW, Intel in a part owner of C|net.

Chapter 7 -- SGI officially releases SGI OGL for the PC, and plans HW kit

On July 15th 1997, John Schimp, from SGI (the company that invented OpenGL), recently wrote the following message on the OpenGL game developer's list.

From:             John Schimpf 
Subject:          OpenGL Release

After a successful beta program for our SW-only (Cosmo OpenGL)
implementation of OpenGL for Windows NT and Windows 95, SGI will
deliver a release version from the same ftp site on Monday 7/21.
Note that we're going to drop 'Cosmo' from the name.  Hopefully this
will eliminate some of the confusion over naming and what is being
provided.  For identification, we'll call it SGI OpenGL for

In addition, we have decided to create a Windows (NT/95) hardware
interface kit based on this software implementation.  The driver kit
will support a rasterization device interface AND will allow IHVs to
support more of the OpenGL pipeline (transforms, lighting, etc.) via
a front end interface.  This also will allow IHVs to add OpenGL
extensions to expose unique hardware features.

We expect to have this kit available in the fall.

SGI will help PC graphics IHVs get OpenGL drivers in place during and
after the development of this driver kit.

John Schimpf
OpenGL Product Manager
Silicon Graphics, Inc.

Thus cementing SGI's commitment to OpenGL for the PC. This announcement came completely unexpectedly and generated a lot of discussion, basically commending SGI, for finally trying to take a leadership role in this area.

In truth half of the debate, when this all started, was that not only is Microsoft dragging their feet about Windows support for OpenGL, but SGI was to be blamed for not taking a leadership role. There were a lot of SGI folks defending their position saying things like "we're not interested in the PC business, we tried it once before and found it to be too much trouble". Not exactly the greatest for their PR.

Anyhow, now we know that in fact, SGI seems to have been planning a move like this, probably for some time. The could come off as real heros if their efforts truly do bear fruit. Certainly their current software OpenGL is a good stepping stone for them, and for developers.

(Indeed, SGI has released SGI OpenGL for Windows a little bit late due to some last minute bug fixing. It can now be found at

Chapter 8 -- Microsoft plays hardball

On July 16, Microsoft's Jay Torborg (a Direct X evangelist) addressed game developers at their Meltdown conference, to inform them that Microsoft would not continue any OpenGL development beyond what they already had available. That is to say, there would be no Direct Draw accelerated OpenGL driver model from them, there would be no further OpenGL support in Memphis, and there would be no hardware accerated OpenGL support from them on either Windows 95 or Windows NT.

He then showed a demonstration of a hacked up mini-OpenGL driver to support GLQuake on top of Direct 3D meaning to be a demonstration that Direct 3D was as good as OpenGL. Of course they neglected to mention that, Quake is an obsolete program that was targetted at Pentium 90s and was released in the middle of 1996. (I wonder if this is grounds for id to sue Microsoft; i.e., a public demonstration of software that does not belong to them. But I guess its not like the id folks to just go suing people.)

Anyhow, I read this to be an incredible opportunity for SciTech (who is authoring their own OpenGL support into their MGL library) as well as SGI and the IHV's which do their own OpenGL support. There is no question games and other content will be coming that require OpenGL, and the winners will be those that support it.

John Carmack had the following reaction to the demo that Microsoft gave:

They wrote an OpenGL emulation layer that translated the calls to D3D. It was a perfectly reasonable bit of technology, but microsoft put an ugly spin on the presentation.

The "Runs faster on D3D" headline is real bullshit. In the body of the text, it admits that it ran slightly slower on identical hardware, but slightly faster on different hardware (the unreleased nvidia RIVA chipset is indeed faster than 3dfx in many cases). That was misleading journalism.

In any case, the D3D / OpenGL argument hasn't been about speed, but about usability, robustness, and portability. Unquestionably D3D has gotten a lot better with DX5 and DrawPrimitive, but it still isn't the best solution.

Nvidia is going to have OpenGL support, so D3D still doesn't offer us any other viable platforms. All the fast cards will have OpenGL support, and the other cards couldn't run Quake anyway. They could have run their D3D emulator on an S3 Virge for a crowd-pleasing 5 fps demo. The apples to oranges headlines could have then read "OpenGL five times as fast as D3D!".

Brian Hook made the following comment in the OpenGL game developer's list in response to a D3D trouble maker:

>The "could we do it" has already been answered.

No it hasn't. What GLQuake uses is a tiny subset of OpenGL. If GLQuake did color+normal at vertices that driver would not have been possible, since Direct3D doesn't support this. If GLQuake had used a feedback buffer, selection buffer, or stencil then that driver would not have been possible.

>The performance was supposedly the same

Kind of hard not to be when you're fill rate limited. That was an amazingly misleading demonstration on the part of Microsoft. I've already voiced my displeasure to the Wave Report (who I've written for before actually) for their particularly biased spin on it.

David Springer (a "personality" on has since (Oct/97) duplicated this Microsoft employee's two weeks of work and distributed his "GLQuake on D3D" patch. (Update: it has been alledged that Springer got his hands on the source for the original Microsoft patch and broke an NDA by releasing it; this is believable since on many occassions he demonstrated that he did not have the competence to implement a GL driver, even a mini GL driver, on his own 11/06/97)

Chapter 9 -- The SciTech/SGI story revealed

Even with all that has happened, it seemed to me that development of OpenGL for mainstream PCs was going to be a slow painful process. The fear of course that it would be too little too late by the time it came out. Indeed if DX6.0 comes out before OpenGL drivers are deployed, then indeed it just might be.

However (and I'm really kicking myself for missing this connection) it turns out that SGI's offer to set up a OpenGL HW porting kit is far more serious than I thought. It turns out SGI and SciTech are working together!! I was floored when I found out about this. SciTech is known for a little program called Display Doctor (formerly called UNIVBE) which basically unifies all advanced graphics adapters under the VESA API. SciTech is also known for delivering. I mean the task they took on is not trivial, yet they've done it and they have a good business based on it. What this means is that SGI will be able to deploy OpenGL drivers for IHVs via SciTech's inside information without the IHV's consent!

Of course, SciTech's drivers are unlikely to be the most optimal, but they will be there, and this alone ought to motivate IHVs to write better drivers using SGIs kit.

Anyhow, here is the net conversation (coming from the OpenGL game developer's list) that tipped me off about this. The conversation it between Tom Ryan, from SciTech Software and some other curious list member:

> Mesa has it's place, and shouldn't go anywhere. Scitech and SGI should
> coordinate their efforts. 
SciTech has been coordinating with SGI for a number of years. As a matter of fact, SciTech first proposed what eventually became Cosmo to SGI back in early 1994. At the time they didn't fully understand that Microsoft was going to try and effectively replace OpenGL with D3D. SciTech did. Eventually, SGI came around and now we have Cosmo.
> I think they both made general announcements about finding a way for
> IHV's to write drivers for OpenGL under Win95. My gusss that now that
> SGI has popped up and said they will be doing it, Scitech wil rely on
> them and not publish anything special for themselves. 
We will be working with SGI in the development of the new hardware abstraction layer. If it sufficiently robust and comes out in a timely manner, we will not need to publish our driver spec. In the mean time, we have now developed internally a standardized the interface to for OpenGL acceleration using SciTech MGL. Right now, this is used for "OpenGL mini-drivers" such as the one used to develop GLQuake and we intend to only support cards that don't fit into the other driver models (right now that means secondary controllers). We encourage all other hardware vendors to support the OpenGL driver interfaces as defined by Microsoft, and eventually SGI, since SciTech MGL supports those implementations as well.
> It wouldn't gain them anything. 
Since SciTech actually develops drivers ourselves, we are in a position to support whatever driver architecture we want internally. As stated above, we encourage hardware vendors to support the interfaces from SGI and Microsoft, but we reserve the right to do anything we want internally to add additional features or performance and to make up for gaps in existing driver architectures.

We want to make sure that anyone using SciTech MGL for development has the fastest access to hardware possible.

Chapter 10 -- Alex St. John speaks, again.

Well, Alex St.John did send his open letter, as promised. You can find it here. Not exactly as inspiring as I'd hoped. But I would like to draw attention to the fact that he had nothing but praise for Carmack, but then decided that he was correct in theory but not in practice. Perhaps in his meetings with Carmack he did not quite learn anything about who Carmack really is. Carmack has been turning theory into reality for as long as he has been programming.

Nevertheless, the inside knowledge is appreciated. Good luck, Alex.

Chapter 10a -- OpenGL/Direct 3D combos.

Inspired by Microsoft's demo of GLQuake on Direct 3D, people have been thinking quite seriously about OpenGL/Direct 3D combinations. Specifically, some guy on the OpenGL game developer's list has proposed a partial OpenGL implementation on top of Direct 3D which he is calling called Utopia GL. This spurred discussion implying that doing Direct 3D on top of OpenGL would probably be easier since OpenGL naturally support more functionality than Direct 3D, thus leading to debate as to whether or not SGI should try to do such a thing. Yet another message announced the impending availablity of a super-set API which could sit on top of either!

Either way, it is very good to hear talk of marginalizing Direct 3D. If these discussions lead to more than just words, it can only help the OpenGL cause and hurt Direct 3D.

Chapter 11 -- Quake 2 Demo Released!

Unfortunately, I do not have access to accelerated OpenGL at the moment, so I am not currently able to experience the Quake 2 demo in its most optimal form. However, it does look a lot better, and even the software rendering version is clearly using a lot of clever special effects. Its a whole heck of a lot harder than Quake.

But most importantly, they did not back down. The software version does not use Direct 3D at all, and the test version supports PowerVR and 3DFX right out of the shute.

Chapter 12 -- Michael Gold leaves SGI

The following discussion hit the USENET on 21/11/97:

Edward Hutchins <> wrote:
>> Author: David Springer <>
>> I realize that your customers are not my customers so you don't give
>> a damn about them.  This is what outrages me about your position.
>Wrong, Gold is at NVidia now... and will no doubt soon know more about
>real 3D customers than you do, oh BIOS king...

    To be pedantic, Springer's customers are not Michael's customers.
Rather, Springer *is* a customer. Michael probably *doesn't* give a damn
about that particular customer.

    As the realization of this unwanted relationship sinks in, Michael
should keep in mind that he's welcome back at any time - though he's able to
act more directly for the success of consumer OpenGL where he is, so OpenGL
wins either way.

    Jon Leech
    Silicon Graphics

The gentlemanly conduct between these people aside, basically this represents a very troubling development for OpenGL on PCs. Up until this point Michael Gold was one of the principle driving forces behind SGI OpenGL for the PC as well as one of its principle coders. Whether or not SGI continues its commitment on SGI OpenGL remains to be seen. (It also remains to be seen if SciTech will step up to the plate and try to drive OpenGL for the PC if SGI starts losing focus as a result.)

I can only assume that he is maintaining his position on OpenGL, and is gambling the the nVidia parts will either dominate the market or gain enough market share to help establish a real OpenGL presence. Indeed, OpenGL will only take off if there are at least a couple of premiere platforms on which it runs. (Though I would hope the situation at nVidia offers him more than this.)

Update: Michael got in touch with me, and assures me that the PC team left at SGI retains the bulk of the brains behind SGI OGL, and that it will not be seriously hurt by his leaving. He also made it clear that his position on OpenGL, and his commitment to supporting it, remain unchanged.

Chapter 13 -- Microsoft throws in the towel

Well, not quite, but at least they've given the appearance of playing nice. Read for yourself:

Monday December 8, 3:47 pm Eastern Time

Company Press Release

SOURCE: Microsoft Corp.

Microsoft and Silicon Graphics Define Distribution and Support of OpenGL on The Windows Platform

Joint Initiative to Enhance OpenGL Acceleration Through New 3-D Graphics Device Driver Kit; New Licensing and Certification Aligns OpenGL for Professional Applications and Direct3D for Consumer Applications

MOUNTAIN VIEW, Calif., and REDMOND, Wash., Dec. 8 /PRNewswire/ -- Microsoft Corp. (Nasdaq: MSFT - news) and Silicon Graphics Inc. (NYSE: SGI - news) today jointly announced plans to deliver a new 3-D Graphics Device Driver Kit (DDK) for the Microsoft(R) Windows(R) operating system. The new DDK will provide graphics chip vendors and OEMs with an easier, more accessible method for creating, certifying and distributing 3-D graphics drivers based on Silicon Graphics(R) OpenGL(R) graphics technology for Windows 95, the Windows NT(R) operating system 4.0 as well as the forthcoming Windows 98 and Windows NT 5.0 operating systems.

OpenGL, a 2-D and 3-D graphics visualization technology created by Silicon Graphics, is an open standard that is governed by an eight-company Architecture Review Board (ARB) of which Microsoft, Silicon Graphics and other leading vendors like Intel Corp. are members.

``Microsoft's support of OpenGL acceleration on all 32-bit Windows platforms is a very important development for both the hardware and software development community,'' said Jon Peddie, president of Jon Peddie Associates of Tiburon, Calif., and one of the industry's leading 3-D graphics analysts. ``By collaborating with Silicon Graphics to encourage high-quality acceleration and consistent deployment of this API, Microsoft is sending a clear signal that it is serious about Windows as a platform for professional 3-D graphics, which is a winning strategy for Microsoft, Silicon Graphics and all developers for Windows.''

``Microsoft is very excited to be working with Silicon Graphics,'' said Kevin Dallas, group product manager for graphics and multimedia at Microsoft. ``This is an initiative that will provide enhanced support for OpenGL professional 3-D applications to Windows 95, Windows 98 and Windows NT. This also reiterates our commitment to OpenGL as the API for professional applications like CAD and to Direct3D(R) for consumer applications like games.''

``Silicon Graphics continues its drive to build the widest possible market for professional-class applications using OpenGL,'' said Shawn Hopwood, senior manager of the graphics API group at Silicon Graphics. ``OpenGL is a vital technology for developers providing high-performance, platform-independent 3-D solutions. We are very pleased to be working with Microsoft to enhance the OpenGL presence on the Windows platform.''

To enable the wide adoption and support of the OpenGL API on the Windows platform, Microsoft will offer chip and graphics hardware developers a direct source for OpenGL DDKs. The new DDK will enable the seamless acceleration of applications based on the OpenGL API on Windows 9X and Windows NT.

As part of the DDK, Microsoft will do the following for developers:

Distribute a new, high-performance OpenGL Installable Client Driver (ICD) developed in cooperation with Silicon Graphics for the Windows 9X and Windows NT environments. Distribute a version of the existing Direct3D API DDK, which can also be found in the DirectX(R) set of APIs DDK. Implement a new certification testing and logo branding program for OpenGL drivers as well as Direct3D drivers created with the DDK through the Windows Hardware Quality Labs. Upon final certification from Microsoft, developers will receive one of the following three branded logos for use with their drivers: Designed for Workstation -- Windows NT 4.0 certified Designed for Windows NT -- Windows NT 5.0 certified Designed for Windows -- Windows 9X and Windows NT 5.0 certified DDK Availability and Developer Information

The new 3-D Graphics DDK for Windows is expected in the spring of 1998 with distribution from Microsoft and joint development and support from Silicon Graphics and Microsoft. For more information on a 3-D Graphics DDK license, developers should e-mail with the subject line ``3-D Graphics DDK Licenses.'' For more information on OpenGL support on Windows, developers should e-mail The OpenGL Architecture Review Board may be found at

Company Information

Silicon Graphics Inc. is a leading supplier of high-performance interactive computing systems. The company offers the broadest range of products in the industry, from low-end desktop workstations to servers and high-end Cray(R) supercomputers. Silicon Graphics also markets MIPS(R) microprocessor designs, Alias/Wavefront(TM) entertainment and design software, and other software products. The company's key markets include manufacturing, government, science and industries, communications and entertainment sectors. Silicon Graphics and its subsidiaries have offices throughout the world and headquarters in Mountain View, Calif.

Founded in 1975, Microsoft is the worldwide leader in software for personal computers. The company offers a wide range of products and services for business and personal use, each designed with the mission of making it easier and more enjoyable for people to take full advantage of the full power of personal computing every day.

NOTE: Microsoft, Windows, Windows NT, Direct3D and DirectX are either registered trademarks or trademarks of Microsoft Corp. in the United States and/or other countries. Silicon Graphics, the Silicon Graphics logo and OpenGL are registered trademarks of Silicon Graphics Inc. Cray is a registered trademark of Cray Research Inc., a wholly owned subsidiary of Silicon Graphics Inc. MIPS is a registered trademark of MIPS Technologies Inc. Alias/Wavefront is a trademark of Alias/Wavefront, a division of Silicon Graphics Ltd. Other product and company names herein may be trademarks of their respective owners.

Industry Applauds Silicon Graphics and Microsoft Agreement

``OpenGL is an important ingredient in Intel's Visual Computing strategy, and Intel is committed to developing products that support both OpenGL and Direct3D. Intel believes this strong signal of support for OpenGL in the Windows environment will further accelerate the growth of high-performance graphics applications on Intel processor-based PCs and workstations.''

- - Jon Khazam Director of Graphics Marketing

Intel Corp.

``3Dlabs applauds the combined efforts of Microsoft and Silicon Graphics to greatly strengthen the capabilities of the Windows platform for professional applications and to enable the widespread availability of OpenGL. As a leading vendor of workstation graphics silicon, we have seen a strong increase in demand for our optimized OpenGL drivers. This announcement gives ISVs a genuine choice of APIs on Windows and provides 3Dlabs the opportunity to further strengthen our support for OpenGL on our range of GLINT and PERMEDIA silicon for all Windows operating systems.''

- - Neil Trevett Vice President of Marketing 3Dlabs Inc.

``By teaming with Silicon Graphics in 3-D technology, Microsoft has provided an opportunity for vendors of high-performance PC graphics solutions, such as Matrox, to push the limits of where professional 3-D on the PC can be taken.''

- - Dan Wood Senior Product Manager Matrox Graphics Inc.

``Not only will the new DDK streamline and simplify the development process, it will also assure developers of the availability of quality OpenGL support on Windows in the future. With the growing industry migration to the Windows NT platform for professional applications, this initiative provides Softimage developers with the access to a cross-platform strategy which is a key component for reaching the largest possible audience.''

- - John McQueen Director of Marketing Softimage, a wholly-owned subsidiary of Microsoft.

``Kinetix worked closely with numerous hardware vendors to ensure quality and performance-oriented OpenGL support in our introduction of 3D Studio MAX R2 last August. The initiative announced today by Microsoft and Silicon Graphics centralizes OpenGL development support for Windows, and will place quality and robust development tools in the hands of the hardware vendors. This is an extremely positive action that will help software developers like Kinetix provide better OpenGL solutions to our professional 3-D graphics customers.''

- - Jimmy Giliberti Senior Director of Product Development Kinetix

``The use of OpenGL for professional applications will allow Alias/Wavefront to more quickly deliver software on a wider variety of hardware platforms that support this standard. The adherence to the OpenGL specification will also result in a more consistent and robust display across multiple platforms. This announcement signals the further confirmation of OpenGL as the standard for high-end graphics. Our customers will definitely benefit from the wider selection of hardware, and from the concentrated development of a single graphics standard.''

- - Peter Ryce PowerAnimator Product Manager Alias/Wavefront

``As the volume provider of 3-D graphics technology to the mainstream PC market, S3 is thrilled at this collaboration between Microsoft and Silicon Graphics to enable the OpenGL and Direct3D APIs to coexist on the Windows platforms. This open approach gives ISVs a clear direction for developing on the two industry-standard 3-D APIs, providing the opportunity for workstation-class and consumer applications to seamlessly play back on Windows 95, Windows 98 and Windows NT.''

- - Michael Howse Director of Marketing, Software Programs S3 Inc.

``We are pleased and excited about this new joint initiative between Microsoft and SGI offering IHVs and ISVs a clear direction for supporting OpenGL on Windows. This announcement allows us to complement our position in the consumer space with high-performance, cost-effective media processors that address the professional application space on the Windows platform.''

- - Andy Keane Vice President of Marketing 3Dfx Interactive Inc.

``Cirrus Logic is pleased to see that Microsoft and SGI have formed an alliance to define the direction and future of OpenGL. We look forward to being able to provide our customers with hardware and drivers that can enable the use of emerging OpenGL professional applications on Windows platforms.''

- - Steven Toteda Product Manager Cirrus Logic

``This collaboration clearly provides a critical component in making high-performance 3-D graphics pervasive on both consumer and professional PC platforms. Developers now have a cohesive content development and playback environment in either Windows or Windows NT. As a leading supplier of high-performance mainstream 3-D processors, this initiative gives us the opportunity to leverage our expertise in the professional market as well.''

- - Michael Hara Director of Strategic Marketing NVIDIA Corp.

SOURCE: Microsoft Corp.

It would be nice to know the inside story here, and I'm sure it will come out soon. Perhaps its really simple: OEMs, and Microsoft's own internal factions (including SoftImage) may have been pressuring them, and with id software basically licensing their Quake 2 technology to basically everyone, this could only be a losing proposition for Microsoft. With the SGI kit basically nearing completion and Quake 2 about to ship (tommorrow, in the US, as of this writing) Microsoft may have decided that the path of the least resistence was the only sensible one.

Ow! Jay Torborg? Eric Angstrom? Philip Taylor? Do you feel that? That's the stinging pain of defeat! Bet you're not feeling too great about some of the comments you guys made and that ridiculous Quake on drugs (i.e., D3D) demo you gave. :o)

Here is a quote that was submitted, but not included:

"Microsoft's endorsement of hardware accelerated OpenGL across both of their desktop operating systems has given us exactly what we want -- the API of our choice on the distribution platforms of our choice." said John Carmack, technical director of Id Software.

Here are the theories I've come across so far:

  1. This means nothing -- Microsoft washes their hands of OpenGL and never has to support it again, basically heaving all the work onto SGI. Microsoft will keep SGI out of the loop and not give them access to internal display technologies.
  2. Michael Abrash threatened to quit again unless they do the right thing. :o)
  3. Realizing that without Microsoft control, the industry might make OpenGL disproportionately fast in comparison to Direct 3D (3DFX as much as openly admits to doing this) Microsoft does this deal to make sure they can cripple the SGI OGL when the time is right.
  4. There's someone out there blackmailing Gates into giving money to Apple, presenting a crappy argument to the court in the DOJ case, supporting OpenGL ... :o)

Strange how I just can't quite bring myself to consider the possibility that they just did the right thing.

Chapter 14 -- Quake 2 Released

I have not yet seen it myself, and do not currently have access to an OpenGL accelerator, however everything I've heard about it says that it does not disappoint. Out of the box it supports 3DFX GL, PowerVR GL and any fully compliant OpenGL drivers. As it arguably represents the most graphically impressive and intensive game for PCs to date, it looks like it is now Direct 3D's turn to play catch up.

Chapter 15 -- SGI Throws in the towel??

Last month, SGI and Microsoft jointly announced a project called Fahrenheit. I have not read all the details, but the gist of it is to somehow subsume OpenGL into it, while unifying behind Direct X, adding new functionality and making it all just one single standard for both PCs and SGI machines. The how and whys have not been answered, and nobody has given me a completely coherent explanation as to why SGI cares to use Microsoft's Direct X standards.

Anyhow, I think SciTech was feeling a little out in the cold, and responded a short time later with a graphics initiative of its own, announcing it on some newsgroups and in mailing lists.

But discussion has started to die down as people are coming to the realization that its vaporware right now.

Chapter 16 -- Mark Kilgard leaves SGI

The following appeared on the OpenGL-game developers list on 03/02/98:

    Mark Kilgard is no longer with SGI, as of last Friday. His web site will
stay around, however. You can direct maintenance requests to me.

    He didn't say where he's going, but I imagine we'll hear from him once
set up at his new job.

    Jon Leech
    Silicon Graphics 

As is well known, Mark Kilgard is a big believer in Open GL. He has written books about it, and has authored many Open GL utilities and samples including GLUT. While his leaving does not necessarily mean anything specific, I'm told Kilgard was simply disgusted with the whole "Fahrenheit" initiative.

(Update: He went to nVidia.)

Chapter 17 -- Eric Engstrom is reassigned

I heard a story that Eric Engstrom, the mutimedia guru over at Microsoft (who in some way over saw Direct X development) was moved to MSN (known internally at Microsoft as the project that only rejects get assigned to.)

I don't have more information. Clearly, I have not been updating this page with the latest info. If you have any other news that you think should be reported here, don't hesitate to mail me about it.

Chapter 18 -- Microsoft inspires some hackers out there

Inspired by Microsoft's minigl wrapper, Khalid Shaikh, a D3D hacker has decided to write a DX portable version of Glide. The story doesn't have anything specifically to do with OpenGL, but its pretty cool. Unfortunately, the lawyers at 3DFX don't seem to think so.

For more info see Khalid's story so far.

Chapter 19 -- SGI's strategy revealed

SGI has unveiled their new Pentium II based visual workstations based on everyone's favourite OS: Windows NT. Of course, this doesn't make sense for SGI unless they are able to leverage all their OpenGL software, which was the real thing they got out of their deal with Microsoft.

So in principle, SGI's strategy is a sound one. Better still since they've announced that they can uninstall NT, and install Linux instead.

This has allowed SGI to drop their MIPs processor technology (which looked like it was going to hit a dead end) and compete in the x86 space at the high end. And its arguably at least as good for OpenGL as it is for Direct 3D.

Its been a year Alex --

About a year ago Alex St. John said that the whole OpenGL thing would go away by now. Yet nearly every major graphics vendor in the industry has jumped on the OpenGL bandwagon. I wish people like Alex St. John could be held accountable for the stupid things they say.

Somehow Alex St. John underestimated (1) the importance of id software, (2) the willingness of graphics companies to add OpenGL to their arsenal as an important differentiator, (3) the number of experts out their willing to do contract work to make OpenGL on PCs really happen. Alex also overestimated the power of Microsoft's will.

And no Alex you can't use the deal between Microsoft and SGI as the real reason why OpenGL is alive today. Probably the real reason why OpenGL is more alive today then ever is because Michael Gold and a number of other SGI, S3 and 3DFX developers (as well as Mark Kilgard later on) decided to work at nVidia and make sure that high quality OpenGL would be brought to market at least on nVidia graphics cards (the desire to do this basically as a way to thumb their noses at Microsoft, is probably one of the most powerful driving forces in the industry right now.) This in turn forced the other serious graphics vendors (ATI, Matrox, 3DFX, and S3 -- Rendition is out of the picture, and nobody takes either Permedia or PowerVR seriously anymore, and well I really don't know or care about the status of Intel/Real3D's graphics efforts) to follow suit. And id software provided the means with which to derive a reward for their efforts (just look on Altavista for web sites with Quake II and Quake 3 benchmarks.)

As the emperor said to Luke: "You will pay for your lack of vision".

I have to be honest. I suspected that Direct X would win in the end not because it was being pushed by Microsoft, but rather because they actually managed to find a way to incorporate certain functionality into it that I felt that the OpenGL ARB would not be able to respond to in a timely manner (most notably Video Textures, as well as Texture Compression.) But none of these potential differentiating factors have shown up on anyone's radar thus far.


Sometimes its hard to be swayed by people who, for whatever reason, you might think are biased for one reason or another. For example, the folks at id, and SGI are used to working with high-end hardware on a day to day basis, so you might want to write them off as not being in touch with the PC industry.

So here are the comments of people in the PC industry, who perhaps, are just writing a game or so, who I myself, may not even know who have had a thing or two to say on the matter:

From: Geoff Allan
Subject: Re: OpenGL and DX6
Date: Wed, 24 Sep 1997 13:08:44 GMT

Sigh. If you can't win an argument with facts, you can always resort to Microsoft Bashing, Deep Dark Mysteries, Confusing the Issue, Name Calling, etc.

Is this a sub-sub-sub thread? Where was everyone? Oh yeah.

I AM on the beta program for DirectX. And I just DID convert my application to OpenGL. And I doubt that I will EVER work with Direct3D again. Why? Because it is NOT the right answer. Is OpenGL? Maybe not. However, there are many games shipping and soon to ship which are 3dfx only. Why?

1) OpenGL is so much easier to code for, there is simply no comparison. The less code YOU write, the less code YOU debug.

2) OpenGL is a more stable API. Microsoft does tend to slap features on everything they undertake, and this can be difficult to work with. DX5 added DrawPrimitive, but what about picking?

3) Many companies are building OpenGL silicon. I saw it at E3, and my mailbox is full of info on new chipsets. The current generation of 3d accelerators, such as the Rage II in my ATI, are crap anyway. The Virge chipset is only an accelerator relative to a 60MHz Pentium. I have to disable hardware acceleration on my ATI to run MotoRacer. Developers HAVE to develop for the next generation, whatever API they use.

4) My app IS a game app. I'm also working on a game engine. If I have to, I'll print "3dfx only" on the box. NOT because I particularly like the 3dfx card, but because it's the only currently shipping product that will help the PC industry keep ahead of the console industry.

5) So there, nyah nyah.

I still think that the basic concepts behind DirectX are good. DirectDraw is blazing fast. DirectSound and DirectPlay work well. I just wish they'd give us a better interface than COM. And I'd like to see "DirectGL", OpenGL on top of the DirectDraw platform.

One of the reasons that many applications don't work properly on several different DirectX installations is simple: the developer is responsible for too much. It seems to me that the installer and the graohics sub-system should be responsible for most of this effort. As a programmer, I shouldn't have to know if the rendering is hardware accelerated or not, but I should be able to find out.

Bandwagon issues, like "Mac vs. PC", "Netscape vs. Internet Explorer", etc., do not interest me. I'm more interested in the facts. Which works best for ME, or MY users? I believe that OpenGL is the right answer, and several months of Direct3d work was replaced with about 3 days work in OpenGL. The end result looks better and runs faster. Period.

Related links:

OpenGL compatible programs:

Games listed on

Please note: my employer does not endorse anything on this page.

I am not a 3D expert by any stretch of the imagination (though I think I understand the basic concepts; I have used IRIS GL in the past, and I know what the basic terminology means.) In my employment so far, I have never been called upon to suggest what my company should do or not do about 3D with respect to hardware design or API usage. Do not hold my company responsible for anything I say, and do not hold me responsible for anything my company does.

Paul Hsieh