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++;
        v->x = 1; v->y = 1; v->z = 0;
        v++;
        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

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.

Signed,

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

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.

The following article is a very interesting, though technical, criticism of Direct3D by graphics engineers at Intel. Check out:

    http://www.techweb.com/se/directlink.cgi?EET19970526S0082

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
       ^^

    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;
    } D3DLVERTEX;

    typedef struct {
      float x, y, z;
      float rhw;  /* Reciprocal of homogenous w. */
      long color, specular;  /* Byte packed! */
      float tu, tv;
    } D3DTLVERTEX;

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);
      glEnableClientState(GL_VERTEX_ARRAY);
      glEnableClientState(GL_NORMAL_ARRAY);
      glEnableClientState(GL_TEXUTRE_COORD_ARRAY);
      glEnableClientState(GL_COLOR_ARRAY);

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)."

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.

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
Windows.

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.
jsch@sgi.com

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!".

>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.

> Mesa has it's place, and shouldn't go anywhere. Scitech and SGI should
> coordinate their efforts. 

> 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. 

> It wouldn't gain them anything. 

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

Edward Hutchins <hutchins@peigu.rest.home.net> wrote:
>> Author: David Springer <springer@matrix.eden.com>
>>
>> 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

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:

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 ihv@microsoft.com with the subject line ``3-D Graphics DDK Licenses.'' For more information on OpenGL support on Windows, developers should e-mail opnglinf@microsoft.com. The OpenGL Architecture Review Board may be found at http://www.opengl.org/.

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.

 
    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 

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.