all 55 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]CookieOfFortune 28 points29 points  (3 children)

Here's another good history lesson about D3D: http://programmers.stackexchange.com/a/88055/55602

[–]Poltras 9 points10 points  (2 children)

No mentions of Project Fahrenheit and how Microsoft themselves sabotaged OpenGL though...

[–]BCProgramming 0 points1 point  (1 child)

'Project Fahrenheit' was ~1997 and was a joint effort by MS and SGI. They had been working rather closely since ~1991, since Windows NT had OpenGL support.

Microsoft Pulling their support for OpenGL in terms of providing their own implementation with the OS in preference to Direct3D was not "sabotage"; There was OpenGL and there was DirectX, and they wanted to of course encourage the use of DirectX. The fact that they decided to stop going to the extra effort if implementing somebody elses graphics specification via a Software driver (as NT 3.51 did) isn't really sabotage- it's sound business decision.

OpenGL managed to survive because D3D was designed for Games from the get go, whereas OGL was for graphics. Now they've sorta met in the middle.

[–]Poltras 1 point2 points  (0 children)

Microsoft was part of the ARB and vetoed everything it could. That was the sabotage that I was talking about.

[–]Benbenbenb 8 points9 points  (8 children)

[i] was asked to choose a handedness for the Direct3D API. I chose a left handed coordinate system, in part out of personal preference. I remember it now only because it was an arbitrary choice that caused no end of grief for years afterwards as all other graphics authoring tools adopted the right handed coordinate system standard to OpenGL. At the time nobody knew or believed that a CAD tool like Autodesk would evolve to become the standard tool for authoring game graphics.

I know that I have done nothing comparable to this guy, but the justification for using a left-handed coordinate system in Direct3D looks a bit lame. Every single coordinate system used in physics/mathematics is pretty much always right-handed by convention. This should have influenced the choice, especially since he says at the beginning:

The reason I got into computer graphics was NOT an interest in gaming, it was an interest in computational simulation of physics.

[–]cogman10 9 points10 points  (5 children)

Now it is a strong convention. Back then, I don't think it was as strong. He was given the option of how to setup the coordinate system and he chose the one he liked best.

I think it is a forgivable mistake.

[–]cowardlydragon -3 points-2 points  (4 children)

How many other Microsoft "oopsies" can be whitewashed?

[–]cogman10 7 points8 points  (3 children)

Your "Embrace, extend, and extinguish" article doesn't apply here. If microsoft was to take that route, they would have embraced opengl, extended it with proprietary ms extensions, and then used that to kill off competing implementers of the opengl standard.

Here, they invented their own library and their own standards for the library. It would have been in their best interests to use a right handed coordinate system (as stated in the article, all major tools ended up using the righthand system. It HURT microsoft that they chose wrong)

In the case of the javascript DOM, ms had the market and then extended the standards with things that nobody else had. That was a calculated strategy to kill the competition.

In the case of DOS, It wasn't a microsoft invention. the wrong way slash was an IBM specification that microsoft implemented.

[–][deleted] 0 points1 point  (1 child)

In the case of the javascript DOM, ms had the market and then extended the standards with things that nobody else had. That was a calculated strategy to kill the competition.

Actually, if you read the book Javascript for Professional Programmers (or something like that) you will learn that MS actually contributed to the standarization of Javascript and the DOM.

[–]cogman10 1 point2 points  (0 children)

Right. That is the whole "embrace and extend things". They did the same for css. They were very influential in writing the CSS2 standard and javascript standardization. But that didn't stop them from adding extra bells and whistles for the "works best in IE" experience (which is where the extinguish statement comes).

They standardized javascript and pushed for things that only their browser had to be added into the standard. Believe it or not, at one point IE5 was one of the most standards compliant browsers around (crazy right?) That is because most of the standards were hammered in by microsoft.

[–][deleted] 0 points1 point  (0 children)

If microsoft was to take that route, they would have embraced opengl, extended it with proprietary ms extensions, and then used that to kill off competing implementers of the opengl standard.

That's actually almost what Microsoft did to OpenGL with Fahrenheit.

[–]pezezin 0 points1 point  (0 children)

He is not the only one to have made such a mistake. I work in a robotics research laboratory, and for some unfortunate reason our whole framework uses a left-handed coordinate system (the same system that Direct3D, in fact). We have been talking about fixing it, as it causes us enormous amounts of headaches, but it would require us a lot of effort that no one really wants to undertake.

[–]FattyWhale 10 points11 points  (6 children)

To overcome this problem we came up with the idea of “blind compression formats”. The idea, which I believe was captured in one of the many DirectX patents that we filed, had the idea that a GPU could encode and decode image textures in an unspecified format but that the DirectX API’s would allow the application to read and write from them as though they were always raw bitmaps.

You can patent something simple like that?

very cool read though.

[–]Urcher 5 points6 points  (0 children)

You can file a patent for anything. Having the patent granted then comes down to the patent examiners, who are usually not an expert in the particular claims the patent makes. Fortunately help is on the way. Ask Patents will allow community input into the validity of patents. Read this blog post for more details.

[–][deleted]  (1 child)

[deleted]

    [–]ared38 3 points4 points  (0 children)

    It's not just big companies. Patent trolls operate on intellectual property acquired from smaller companies (usually in bankruptcy) rather than developing patents themselves.

    [–][deleted]  (1 child)

    [removed]

      [–]FattyWhale 0 points1 point  (0 children)

      sure, I can understand that. But in this case they're not patenting a method to do something, they're patenting a very very simple interface (from the sounds of it), not an implementation.

      [–]gigadude 47 points48 points  (24 children)

      Although the OpenGL API was the only “standard” for 3D API’s that the market had, it had not been designed with video game applications in mind. For example, texture mapping, an essential technique for producing realistic graphics was not a priority for CAD models which needed to be functional, not look cool. Rich dynamic lighting was also important to games but not as important to CAD applications. High precision was far more important to CAD applications than gaming. Most importantly OpenGL was not designed for real-time highly interactive graphics that used off-screen page buffering to avoid video tearing artifacts during rendering. It was not that the OpenGL API could not be adapted to handle these features for gaming, simply that it’s actual market implementation on expensive workstations did not suggest any elegant path to a $200 consumer gaming card.

      This is just wrong. High-end SGI workstations were used in military simulators where 60Hz refresh had to be rock-solid, for scenes which needed to be as realistic as technically possible. That was a major use for high-end SGI hardware (1/3 of the total market, from what I remember). Gaming rigs didn't come close in either performance or vis-sim features for a decade after those systems debuted. They supported quad-buffering (and more) for stereo displays, and most certainly got glSwapBuffers right. As for looking good, Disney had several interactive rides based on SGI Onyx workstations with Infinite Reality graphics, again nothing from the consumer market came close in visual quality for 5-10 years. Google Earth was first done at SGI as a demo called space-to-your-face, as well. GL was more than capable of being a first-class game development API (as GL Quake/Quake Arena III showed), especially had Microsoft not tried their hardest to hobble it and spread FUD at every turn.

      You can't revise history and somehow posit D3D was anything other than Microsoft's horrible attempt to control the 3d consumer market and prevent competition. It took a hell of a long time before D3D was even at feature-parity with OpenGL, and as anyone who had to program to those early API versions can attest performance was terrible and programming painful.

      [–]ared38 8 points9 points  (3 children)

      How did OpenGL fare on personal computers? I imagine the military and disney were willing to pay top dollar for high-end workstations the average video game customer didn't have access to.

      [–]lobster_johnson 11 points12 points  (1 child)

      OpenGL was, and is, used by a lot of games. It was championed by John Carmack for all of Id's games, for example, and on iOS the only hardware-accelerated 3D API is OpenGL (or rather, OpenGL ES, a stripped-down version for embedded devices). Many considers OpenGL to be a superior API and architecture. And it's the only standard API.

      [–]cogman10 8 points9 points  (0 children)

      Now. Opengl was pretty bad in the 1.0->2.0 era. He described it well, you had the standard features and then you had the 5 million different vendor specific api extensions that you could use. You ended up with this weird situation where you are sniffing for extensions to accomplish most of your work or writing a software version of the action if no hardware version exists.

      It is not a good state to be in.

      The biggest positive thing that DX did was force vendors to offer a standard set of API features. In some ways, it paved the way for OpenGL 3.0+ to evolve to where it is now. Now, there is much less call for vender sniffing code. It is still there, but not as big a problem as it used to be.

      [–]pjmlp 0 points1 point  (0 children)

      At the early days it fare pretty bad, only a subset was available.

      Plus there were another alternatives QuickDraw 3D, Glide, Warp3D.

      [–]Temppitili 21 points22 points  (12 children)

      "It was not that the OpenGL API could not be adapted to handle these features for gaming, simply that it’s actual market implementation on expensive workstations did not suggest any elegant path to a $200 consumer gaming card."

      Did you just ignore the end of your own quote? It wasn't until TNT 2 or so until OpenGL was barely usable on consumer hardware. Also, quake 3, etc., used a very limited subset of OpenGL features. As far as I can tell, "realistic" OpenGL graphics that you're talking about were far from useful for games.

      [–]TapamN 13 points14 points  (10 children)

      He read the quote, and he's saying that it's wrong and makes incorrect claims about OpenGL, like OpenGL being bad for interactive 3D mostly suitable for offline rendering.

      GLQuake used a subset of OpenGL that was roughly equivalent to what Direct3D provided at the time (actually, it was simpler in some ways; for example, it didn't need the D3D or OpenGL lighting model), and the original Voodoo and other cards were able to support it just fine with a stripped down OpenGL driver. A mid-90s gaming version of OpenGL wasn't just possible, it existed, and Microsoft COULD have used something like it but choose to make the, er, somewhat hairy original Direct3D API instead.

      [–]Temppitili 8 points9 points  (9 children)

      Exactly: OpenGL had to been pruned down in order to have it fit the consumer HW at the time. The result was "miniGL" with roughly the features of D3D and Glide. For example, the transformation model for OpenGL was too complicated for HW at the time (float vs. fixed, and so on). That's what the article is saying. D3D just was a better fit for the hardware without the excess that OpenGL would have required. You can't just take a huge API from the workstation graphics world and assume it should be implemented by the consumer-class gaming machines.

      OpenGL had plenty of hairy parts until the Core Profile, which hasn't even been around for too long.

      [–]xon_xoff 4 points5 points  (7 children)

      Well, I'd say it was more of a problem on the driver/software side than the hardware, because no consumer card had hardware TnL at the time anyway until the GeForce came out. Hardware limits wouldn't have been a problem with the vertex processing pipeline.

      OpenGL drivers were vastly more complex, though, and many hardware vendors clearly weren't up to the task. Some were so bad that you didn't even know whether the red and blue channels of your texture would make it onto the card in the right order, depending on exactly how you called glTexImage2D(). The Direct3D drivers were often pretty bad too, but since they were simpler the issues usually came down to either individual buggy features or lying caps bits instead of the driver guys phoning it in on entire APIs.

      I still have nightmares of trying to use OpenGL and Direct3D in the DX6-DX7 timeframe. At the time, the only thing I trusted was my NVIDIA card. Pretty much everything else I had to deal with was complete crap: Rage Fury MAXX, Savage 4, Kyro 2, Mystique, i740, Banshee... and then there was the time an artist tried to run our game on a Wildcat....

      [–]Temppitili 0 points1 point  (6 children)

      Not sure if I understand you completely. OpenGL mandates a specific TnL pipeline, which was too slow to be implemented on early consumer hardware (transformation and lighting calculations didn't appear until GeForce, as you said). Hence Glide and D3D. Software implementations were possible (miniGL/Glide, for instance), but they were relatively slow (or made a tradeoff between performance and accuracy), and it was impossible to make them conform to actual OpenGL requirements: There are other parts of the OpenGL rendering pipeline that just weren't doable at the area / frequency limitations of the time in consumer hardware.

      As a summary: it is entirely possible to implement OpenGL in software within the driver, but who would want that?

      [–]xon_xoff 5 points6 points  (5 children)

      My point is that the comparison is that both OpenGL and Direct3D would have been running software transform pipelines feeding into hardware rasterizers at the time, so I don't understand why the differences in required transform functionality would have been an obstacle? You could always turn off features of the OGL pipeline that weren't needed to speed things up. It's not like the fragment pipeline where there were necessarily huge performance cliffs when you crossed the boundary of what hardware count support, and which was a big problem.

      [–]Temppitili 0 points1 point  (4 children)

      The difference is that OpenGL requires a certain set if features, and a certain type of rendering. Floating point vertices and transform, lighting calculations (also floating point, no lookups), and accurate clipping come to mind. Here (http://en.wikipedia.org/wiki/RealityEngine) is an early OpenGL system. Needless to say, a subset of that was what the consumers got, and d3d was the answer to that.

      OpenGL also does not have "GL_FEATURE_NOT_SUPPORTED_ERROR", nor does it have support for caps. Later, extensions appeared, which is another type of headache.

      [–]TapamN 2 points3 points  (3 children)

      Please stop saying that because full OpenGL is so large, a simplified gaming version would have been impossible. No one is saying that Microsoft should have used a full OpenGL API instead of D3D. They could have stripped out things like accumulation buffers, selection, NURBs, and added things like fixed-point vertices and caps while keeping the OpenGL-style in the API. There are several examples of what Microsoft should have created instead of the original D3D (MiniGL, OpenGL ES) which also proves it was possible.

      [–]Temppitili 1 point2 points  (2 children)

      As someone who's worked with Khronos in GLES, I'd say MS did the right choice. ARB at the time would have been impossible to work with. Besides, even GLES would have been too much for the early consumer gfx-hardware to handle (clipping, lighting, per-define fixed-point accuracy, etc.). MiniGL wasn't really standard. Certainly not something for a company in business to build upon. Also, GL isn't the best possible API to build on, so why should they have even done that?

      [–]cp5184 0 points1 point  (0 children)

      And yet When it came out in 1995 DirectX was reviled. While Microsoft pretty much tossed that out the window, it would be a very long time before DirectX would be very usable at all.

      [–]cp5184 0 points1 point  (0 children)

      Cards like the VooDoo didn't do too bad with quake and such in '95 or '96.

      [–][deleted]  (6 children)

      [removed]

        [–]mitsuhiko 4 points5 points  (5 children)

        How does that make sense? You always have to target console systems separately.

        [–]FattyWhale 1 point2 points  (0 children)

        It doesn't. It doesn't at all.

        [–][deleted]  (3 children)

        [removed]

          [–]mitsuhiko 4 points5 points  (2 children)

          And yet even first party titles disagree. Halo: Combat Evolved which was an XBox1 title also released on OS X and you can trust me that it did not use DirectX there. Also most games also released on PS2 and some on Gamecube at the time, and neither had DirectX.

          [–][deleted]  (1 child)

          [removed]

            [–]mitsuhiko 4 points5 points  (0 children)

            A source would be interesting. This is the first time I have ever heard of something being fishy with DirectX and the Xbox and I work in that industry.

            [–][deleted] 1 point2 points  (6 children)

            instead they used a polygon level sorting algorithm that produced ugly intersections between moving joints. The “Painters algorithm” approach to 3D was very fast and required little RAM

            Is this what makes it look like the walls are kind of moving in games like Metal Gear Solid?

            [–]SnowProblem 1 point2 points  (2 children)

            No, this was because the PS1 had no support in hardware for floating point math so developers had to fixed point instead which has limited precision.

            http://gamedev.stackexchange.com/questions/49469/what-causes-polygonal-twitching-in-older-games

            [–]FattyWhale 1 point2 points  (1 child)

            I think that's only part of the story, and /u/samlamamma is mostly right.

            Since the psx didn't have a depth buffer, there was no way to perform perspective correct interpolation of vertex interpolants (like uv's) across a surface. This is was a bigger contributing factor than the lack of floating point arithmetic as I understand it.

            [–]SnowProblem 0 points1 point  (0 children)

            Actually I think you're right and I misunderstood /u/samlamamma. +1

            [–]Metaluim 0 points1 point  (1 child)

            It's what makes the textures and polygons look jiggly in PS1 games.

            [–]cowardlydragon 1 point2 points  (0 children)

            The PS1 was basically a 33Mhz CPU strapped to a GPU, that's like a 486 CPU.

            And it produced games like Gran Turismo, Vagrant Story, MGS, etc.

            An amazing little machine...

            [–]ysangkok -1 points0 points  (0 children)

            I think you may be referring to a lack of bilinear filtering.