Direct3D, OpenGL, Metal, Full Circle

Since I’m getting so much grief about Apple’s implicit announcement that they are ditching OpenGL support at their WWDC event last week, I thought I would take a quick jaunt down memory lane to attempt to illustrate the immense irony and hilarity of all of this for me personally.  Attached below is the original Direct3D API overview from 1996 describing the goals and feature set of Direct3D 1.0. This document was written in part by myself and members of the early DirectX team almost 20 years ago.

I’d just like to point out a few of the funny bits that have come full circle over 20 years which have been giving me a sense of deja-vu this week.  Let’s start with WHY OpenGL survived to the present day as an Open 3D API standard at all.  As many who read my articles will recall, SGI was the standard bearer for OpenGL in the early days, it was “open” primarily because SGI was essentially the only hardware vendor that supported it, so it’s openness was irrelevant given that you could only buy SGI hardware to get hardware accelerated OpenGL (IrisGL)  support.  Its original purpose was for CAD/CAM applications as such the earliest version of OpenGL and early OpenGL hardware didn’t support texture mapping… one of the first and most important 3D features games needed.  As SGI was dying Microsoft licensed OpenGL from SGI in exchange for a licensing deal with SGI to replace their Unix platform with Windows NT.  It was this deal that led Microsoft to devote tremendous resources and effort to supporting OpenGL even as SGI faded from the scene.  Microsoft had no intention of making OpenGL useful for gaming or available to consumers for gaming on its consumer operating systems like Windows 95.  To do so would require inventing a new 3D driver model for consumer 3D hardware that didn’t exist at that time.   Game developers certainly had no use or desire for OpenGL at that time because of course it was completely useless for games without consumer gaming hardware or robust support for texture mapping.

The very first public documentation for the Direct3D API expresses this issue as follows;


OpenGL is a precise 3D technology used for high-end CAD/CAM, modeling and animation, simulations, scientific visualization, and other exacting 3D-image rendering. It is provided with Windows NT and is available to you for use with Windows 95. Putting OpenGL on Windows 95 means that you can run Win32 OpenGL applications on any Win32 workstation. OpenGL currently takes advantage of any high-end hardware that has OpenGL functionality, using a client driver model designed for OpenGL. A future release of OpenGL will be able to take advantage of lower-priced 3D hardware (provided that it supports the precision conformance requirements of OpenGL) through the Direct3D API, providing a hardware solution that complements Direct3D.

In other words, one of the PURPOSES of the Direct3D API was to bring the OpenGL API to the Windows 95 consumer OS in anticipation that consumer hardware that could support it would eventually arrive and that Direct3D would be the DRIVER layer that enabled it to work on that hardware.  Neither Microsoft nor the early DirectX team imagined that the decision to SUPPORT OpenGL on consumer hardware with a DRIVER layer in Windows 95 would result in a competition between the high level OpenGL API and the low-level Direct3D DRIVER LAYER.  Here’s how the early Direct3D documentation describes the relationship that Direct3D was expected to have to high-level API’s like OpenGL.

The Microsoft family of advanced 3D-graphics solutions includes the Direct3DTM and OpenGL® application programming interfaces (APIs).  The relationship between the Windows graphics systems, applications written with the Win32® API, the rest of the Windows system, and the hardware is shown in the following illustration.

D3D1In other-words Direct3D 1.0 was Microsoft’s driver layer for the consumer version of OpenGL intended to produce a generation of low cost consumer 3D hardware that could support OpenGL based CAD/CAM applications.  We DID NOT anticipate that anybody would want to use OpenGL for games given it’s inherent limitations for gaming.  We Imagined that game engines like the Quake engine and/or the Unreal engine would fill that niche.  Without that driver support from Microsoft there would have been no practical way to use the OpenGL API for consumer applications on Windows.  Microsoft provided a high-level scene API with Direct3D called Retained Mode because there were no API’s that provided game-like 3D functionality at that time.  We wanted to see hardware accelerated lighting, transformation, texture mapping and Z-buffers become a staple for 3D hardware, so we provided an API that applications could use and exposed them for hardware acceleration to help incentivize consumer 3D chip makers to support those features.  We didn’t IMAGINE that doing this would spark an API war.

Retained Mode

Direct3D Retained Mode API is designed for manipulating 3D objects and managing 3D scenes. Retained Mode makes it easy to add 3D capabilities to existing Windows-based applications or to create new 3D applications. Its built-in geometry engine supports advanced capabilities like key frame animation and frees you from creating object databases and managing the internal structures of objects. In other words, after using a single call to load a predefined 3D object, the application can use simple methods from the API to manipulate the object in the scene in real-time without having to work explicitly with any of the internal geometry.

See… no mention of using the Retained Mode API to specifically make games.  We thought game developers would adopt Immediate Mode, because that’s what the early 3D game engine luminaries like John Carmack and Tim Sweeney had personally told me they wanted.  We anticipated that the game engines would come from THEM because OpenGL sucked for gaming applications… 20 years ago…

Here’s a diagram of the early Direct3D driver architecture as we designed it to CREATE the market for modern consumer 3D hardware, which as we all know today, it succeeded at.


That all worked according to plan.  Then things started to get silly.

Execute Buffers

Each of the three modules in the rendering engine maintains state information that is set by using the Direct3D API. After all the state information is set, the rendering engine is ready to process display lists, which are known as execute buffers. Your application works explicitly with execute buffers only in Immediate Mode; Retained-Mode applications work at a higher level than this.

Execute buffers are fully self-contained, independent packets of information. They contain a vertex list followed by an instruction stream. The instruction stream consists of operation codes, or opcodes, and the data that is operated on by those opcodes. Direct3D’s opcodes are listed in the D3DOPCODE enumerated type. The D3DINSTRUCTION structure describes instructions in an execute buffer; it contains an opcode, the size of each instruction data unit, and a count of the relevant data units that follow.

execute buffers

Those of you who have read the new Apple Metal API documentation may recognize Execute Buffers as the ancient analog to the Apple Metal API’s modern Command Buffers.  Execute buffers were a very low-level construct designed to give game developers full, FAST, access straight to raw 3D hardware performance.  They were complicated to use and it took nearly a page of code just to draw a triangle on the screen… just like Metal needs NOW 20 years later!  What happened to Direct3D Execute Buffers?  Game developers cried about them being too complicated… they wanted something simpler to use which they claimed they got from an API like OpenGL.  Since OpenGL had other serious limitations for gaming and was an OPEN API that we couldn’t just freely modify, we put these capabilities into the higher level Direct3D API’s… thus making the Direct3D API more analogous to OpenGL itself.  Why is this funny today?  Take a look at the comment I got from one of my readers about why they are UPSET with me for pointing out that Apple is abandoning OpenGL support…

“OpenGL has been held hostage by CAD companies for over a decade. That is why ES was created”

Nearly twenty years later OpenGL still sucks for games, OpenGL drivers are STILL consistently broken across devices,  OpenGL  is still driven by CAD applications and Apple is engaged is launching its own Direct3D like API to try to deal with it.  Like the early DirectX API it even appears that the Metal API is intended to underlie higher-level API’s like OpenGL, just as Microsoft attempted in 1995.   Now that’s progress…

Finally to  commemorate nearly 20 years of dedicated research and progress in the field of 3D graphics we have the original Direct3D code required to draw a single 3D triangle on a computer screen accompanied by the equivalent code 20 years later… for the Metal API.

 *  Copyright (C) 1995, 1996 Microsoft Corporation. All Rights Reserved.
 *  File: triangle.c

#include "d3d.h"
#include "d3ddemo.h"

static D3DEXECUTEDATA d3dExData;
#define NUM_VERTICES 3

OverrideDefaults(Defaults* defaults)
    lstrcpy(defaults->Name, "Triangle D3D Example");
    defaults->rs.bPerspCorrect = FALSE;
    defaults->bResizingDisabled = TRUE;

            LPD3DRECT lpExtent)
     * Execute the instruction buffer
    if (lpDev->lpVtbl->BeginScene(lpDev) != D3D_OK)
        return FALSE;
    if (lpDev->lpVtbl->Execute(lpDev, lpD3DExBuf,
                               lpView, D3DEXECUTE_UNCLIPPED) != D3D_OK)
        return FALSE;
    if (lpDev->lpVtbl->EndScene(lpDev) != D3D_OK)
        return FALSE;
    if (lpD3DExBuf->lpVtbl->GetExecuteData(lpD3DExBuf, &d3dExData) != D3D_OK)
        return FALSE;
    *lpExtent = d3dExData.dsStatus.drExtent;
    return TRUE;



    return TRUE;

           LPDIRECT3DVIEWPORT lpView, int NumTextures,
           LPD3DTEXTUREHANDLE TextureHandle)
    LPVOID lpBufStart, lpInsStart, lpPointer;
    size_t size;
    int t[8][3] = {
        0, 1, 2,
    D3DMATERIAL bmat, mat;

    if (lpD3D->lpVtbl->CreateMaterial(lpD3D, &lpBmat, NULL) != D3D_OK) {
        return FALSE;
    memset(&bmat, 0, sizeof(D3DMATERIAL));
    bmat.dwSize = sizeof(D3DMATERIAL);
    bmat.diffuse.r = (D3DVALUE)1.0;
    bmat.diffuse.g = (D3DVALUE)1.0;
    bmat.diffuse.b = (D3DVALUE)1.0;
    bmat.ambient.r = (D3DVALUE)1.0;
    bmat.ambient.g = (D3DVALUE)1.0;
    bmat.ambient.b = (D3DVALUE)1.0;
    bmat.hTexture = TextureHandle[0];
    bmat.dwRampSize = 1;
    lpBmat->lpVtbl->SetMaterial(lpBmat, &bmat);
    lpBmat->lpVtbl->GetHandle(lpBmat, lpDev, &hBmat);
    lpView->lpVtbl->SetBackground(lpView, hBmat);

    if (lpD3D->lpVtbl->CreateMaterial(lpD3D, &lpMat1, NULL) != D3D_OK) {
        return FALSE;
    memset(&mat, 0, sizeof(D3DMATERIAL));
    mat.dwSize = sizeof(D3DMATERIAL);
    mat.diffuse.r = (D3DVALUE)1.0;
    mat.diffuse.g = (D3DVALUE)1.0;
    mat.diffuse.b = (D3DVALUE)1.0;
    mat.ambient.r = (D3DVALUE)1.0;
    mat.ambient.g = (D3DVALUE)1.0;
    mat.ambient.b = (D3DVALUE)1.0;
#define SPECULAR
    mat.specular.r = (D3DVALUE)1.0;
    mat.specular.g = (D3DVALUE)1.0;
    mat.specular.b = (D3DVALUE)1.0;
    mat.power = (float)40.0;
    mat.specular.r = (D3DVALUE)0.0;
    mat.specular.g = (D3DVALUE)0.0;
    mat.specular.b = (D3DVALUE)0.0;
    mat.power = (float)0.0;
    mat.hTexture = TextureHandle[1];
    mat.dwRampSize = 16;
    lpMat1->lpVtbl->SetMaterial(lpMat1, &mat);
    lpMat1->lpVtbl->GetHandle(lpMat1, lpDev, &hMat1);
     * Setup vertices
    memset(&src_v[0], 0, sizeof(D3DVERTEX) * NUM_VERTICES);
    /* V 0 */
    src_v[0].sx = D3DVAL(10.0);
    src_v[0].sy = D3DVAL(10.0);
    src_v[0].sz = D3DVAL(0.1);
    src_v[0].rhw = D3DVAL(1.0);
    src_v[0].color = RGBA_MAKE(255, 0, 255, 255);
    src_v[0].specular = RGB_MAKE(0, 0, 255);
    src_v[0].tu = D3DVAL(0.0);
    src_v[0].tv = D3DVAL(0.0);
    /* V 1 */
    src_v[1].sx = D3DVAL(300.0);
    src_v[1].sy = D3DVAL(50.0);
    src_v[1].sz = D3DVAL(0.9);
    src_v[1].rhw = D3DVAL(2.0);
    src_v[1].color = RGBA_MAKE(255, 255, 255, 255);
    src_v[1].specular = RGB_MAKE(0, 0, 0);
    src_v[1].tu = D3DVAL(1.0);
    src_v[1].tv = D3DVAL(1.0);
    /* V 2 */
    src_v[2].sx = D3DVAL(150.0);
    src_v[2].sy = D3DVAL(180.0);
    src_v[2].sz = D3DVAL(0.6);
    src_v[2].rhw = D3DVAL(1.0);
    src_v[2].color = RGBA_MAKE(255, 255, 0, 255);
    src_v[2].specular = RGB_MAKE(0, 0, 0);
    src_v[2].tu = D3DVAL(0.0);
    src_v[2].tv = D3DVAL(1.0);
     * Create an execute buffer
    size = sizeof(D3DVERTEX) * NUM_VERTICES;
    size += sizeof(D3DINSTRUCTION) * 6;
    size += sizeof(D3DSTATE) * 2;
    size += sizeof(D3DPROCESSVERTICES);
    size += sizeof(D3DTRIANGLE) * 1;
    memset(&debDesc, 0, sizeof(D3DEXECUTEBUFFERDESC));
    debDesc.dwSize = sizeof(D3DEXECUTEBUFFERDESC);
    debDesc.dwFlags = D3DDEB_BUFSIZE;
    debDesc.dwBufferSize = size;
    if (lpDev->lpVtbl->CreateExecuteBuffer(lpDev, &debDesc, &lpD3DExBuf,
                                           NULL) != D3D_OK) {
        return FALSE;
    if (lpD3DExBuf->lpVtbl->Lock(lpD3DExBuf, &debDesc) != D3D_OK) {
        return FALSE;
    lpBufStart = debDesc.lpData;
    memset(lpBufStart, 0, size);
    lpPointer = lpBufStart;

     * Copy vertices to execute buffer
    VERTEX_DATA(&src_v[0], NUM_VERTICES, lpPointer);
     * Setup instructions in execute buffer
    lpInsStart = lpPointer;
    OP_STATE_LIGHT(1, lpPointer);
    OP_PROCESS_VERTICES(1, lpPointer);
                             D3DPROCESSVERTICES_UPDATEEXTENTS, 0, NUM_VERTICES, lpPointer);
    OP_STATE_RENDER(1, lpPointer);
        STATE_DATA(D3DRENDERSTATE_TEXTUREHANDLE, TextureHandle[1], lpPointer);
     * Make sure that the triangle data (not OP) will be QWORD aligned
    if (QWORD_ALIGNED(lpPointer)) {
    OP_TRIANGLE_LIST(1, lpPointer);
        ((LPD3DTRIANGLE)lpPointer)->v1 = 0;
        ((LPD3DTRIANGLE)lpPointer)->v2 = 1;
        ((LPD3DTRIANGLE)lpPointer)->v3 = 2;
        lpPointer = ((char*)lpPointer) + sizeof(D3DTRIANGLE);
     * Setup the execute data
    memset(&d3dExData, 0, sizeof(D3DEXECUTEDATA));
    d3dExData.dwSize = sizeof(D3DEXECUTEDATA);
    d3dExData.dwVertexCount = NUM_VERTICES;
    d3dExData.dwInstructionOffset = (ULONG) ((char *)lpInsStart - (char *)lpBufStart);
    d3dExData.dwInstructionLength = (ULONG) ((char *)lpPointer - (char *)lpInsStart);
    lpD3DExBuf->lpVtbl->SetExecuteData(lpD3DExBuf, &d3dExData);

    return TRUE;

And the Apple Metal API code for drawing a single 3D triangle… down to only 35 lines of code, imagine what another 20 years will bring?

static const float posData[] = {
0.0f, 0.33f, 0.0f, 1.f,
-0.33f, -0.33f, 0.0f, 1.f,
0.33f, -0.33f, 0.0f, 1.f,
static const float colorData[] = {
1.f, 0.f, 0.f, 1.f,
0.f, 1.f, 0.f, 1.f,
0.f, 0.f, 1.f, 1.f,
id  commandQueue = [device newCommandQueue];
id  commandBuffer = [commandQueue commandBuffer];
id  posBuf = [device newBufferWithBytes:posData length:sizeof(posData) options:nil];
id  colBuf = [device newBufferWithBytes:colorData length:sizeof(colorData) options:nil];
MTLAttachmentDescriptor *colorAttachment = [MTLAttachmentDescriptor attachmentDescriptorWithTexture:currentTexture];
[colorAttachment setLoadAction:MTLLoadActionClear];
[colorAttachment setClearValue:MTLClearValueMakeColor(0.0,0.0,1.0,1.0)];
MTLFramebufferDescriptor *fbDesc = [MTLFramebufferDescriptor framebufferDescriptorWithColorAttachment:colorAttachment];
id  framebuffer = [device newFramebufferWithDescriptor:fbDesc];
id  renderEncoder = [commandBuffer renderCommandEncoderWithFramebuffer:framebuffer];
NSError *errors;
id  library = [device newLibraryWithSource:progSrc options:nil error:&errors];
id  vertFunc = [library newFunctionWithName:@"hello_vertex" options:nil error:&errors];
id  fragFunc = [library newFunctionWithName:@"hello_fragment" options:nil error:&errors];
MTLRenderPipelineDescriptor* pipelineDesc = [MTLRenderPipelineDescriptor new];
[pipelineDesc setVertexFunction:vertFunc];
[pipelineDesc setFragmentFunction:fragFunc];
[pipelineDesc setPixelFormat:currentTexture.pixelFormat atIndex:0];
pipeline = [device newRenderPipelineStateWithDescriptor:pipelineDesc error:&errors];
[renderEncoder setRenderPipelineState:pipeline];
[renderEncoder setVertexBuffer:posBuf offset:0 atIndex:0];
[renderEncoder setVertexBuffer:colBuf offset:0 atIndex:1];
[renderEncoder drawPrimitives:MTLPrimitiveTypeTriangle vertexStart:0 vertexCount:3];
[renderEncoder endEncoding];
[commandBuffer commit];




  1. And where’s the code to do this in OpenGL 4.4 ?

  2. Apples and oranges much?

    You can’t compare code examples and APIs that are 20 years apart. You may as well compare low level APIs with middleware like Unreal Engine or Unity.
    You forgot to attach the shaders for the metal version.
    A better comparison would be modern DX vs modern OpenGL vs Metal vs the AMD/nVidia ones.

    • I’m sure, THE POINT is that gaming industry cut their own throats 20y ago, MS was naive (greedy?) enough to go with it, and that those design principles are being validated right now… by gaming industry. 😀

      • Well may I suggest reading the other stories about it in my blog. The answer to your question can be found by searching for “Talisman” on my site. The early Nvidia and XBOX creation stories are there as well. You can also find the stories about how Microsoft inadvertently handed Abode Flash the online game platform business after screwing up Java support with Sun. Had Microsoft NOT screwed up with Sun all modern online games would probably be Java based, as my own company, WildTangent was in that era.

        To be fair, MICROSOFT cut a few throats back then including NOT helping the OpenGL problem as originally intended and Microsoft has profited from it all immensely in the form of the XBOX and Windows based consumer OS sales which combined with DirectX on the PC created the modern US game industry. The OpenGL API WAS FORCED by DirectX to assume its modern structure for better or worse because had Microsoft NOT supported 3D gaming on Windows, there would never have been a PC market for 3D games or a game console based on a non-proprietary Japanese 3D chip. OpenGL would have been relegated to CAD and maybe movie applications and played no role in gaming because the Japanese console makers would never have adopted any API but their own closed libraries for 3D. (Search “Japan” on my blog for the stories about Microsoft’s interactions with Nintendo, Sony and Sega from that era.) Without a Windows driver model for 3D chips, OpenGL would NOT have worked on the PC for gaming.

        • …assuming no one else was willing to step in and fill that void. Just because Microsoft played a significant role with its decisions, that doesn’t mean OpenGL would have stayed relegated to CAD. Nature abhors a vacuum. It’s unlikely that this one would have stood for very long, even without Microsoft’s influence. Another entity would surely have stepped up, and leveraging an existing and available architecture like OpenGL — primitive though it may have been at the time — made more sense than starting from scratch.

          • In this case the void was either going to be filled by Talisman or by nothing. You seem to be selectively ingnoring the observation that Microsoft controlled the OS which was horrendously broken for gaming in many ways other than 3D. Had Microsoft NOT made gaming a focus there would have simply been no PC game market because NOBODY else could fix it. The only reason OpenGL drivers are possible under Windows is because Microsoft enabled them as part of the work to support Direct3D. The console game market was dominated by Japanese consoles at the time and the Japanese had NO desire to support open API’s so the consumer game market most certainly would NOT have ended up on OpenGL. It would have been a fragmented mash of proprietary 3D API’s tied to specific vendor hardware just as Nvidia and 3DFX had intended before DirectX. The only way to make games work on Windows WITHOUT Microsoft support was to supply entire hardware solutions and write all the drivers yourself to basically offload the game… which was what Nvidia’s first PC Card was intended to do.

          • > Had Microsoft NOT made gaming a focus there would have simply been no PC game market because NOBODY else could fix it.

            Allow me to broaden the scope of your statement, if I may…

            Had Microsoft not made gaming a focus, the PC game market would simply have evolved using a different platform — possibly one better suited than Windows. (That’s right, I said it.)

            Now granted, Microsoft was in prime position, and they seized that bull by the horns. Good on them, but remember we’re speaking speculatively as if they hadn’t. That opens up avenues far wider than just Windows for gaming to follow. I don’t think anyone can deny how crucial a moment this was in Windows’s history, and let’s not forget the hostility game developers of the era had for Microsoft at the time. I’m certainly not saying that the game industry is what drove Windows’s market penetration, but I am saying it was a significant factor, and remains one.

            All that being the case, I fail to see what OpenGL has to thank Microsoft for. In a topic so riddled with “what-ifs” you have to accept that it would likely have played out any number of ways, with any number of players, sans anything to do with Microsoft or it’s OS. Would it have happened on the same timetable? Probably not, but that doesn’t mean it wouldn’t have happened, or that OpenGL wasn’t the logical place to turn to see it through.

          • Well the point of the article is that in that time and place there were NOT actually a lot of obvious paths the game industry could have taken. Nobody but Microsoft could fix games on Windows and SGI was dead so ONLY Microsoft was investing in OpenGL support in that era. SGI did the Fahrenheit deal with Microsoft which was basically handing control of the OpenGL spec to Microsoft so whatever you may think of it, OpenGL owes it’s survival into the modern era to Microsoft support for it and to Direct3D enabling support for it in a consumer version of Windows that otherwise would not have had an OpenGL driver model. Even if OpenGL had worked great the rest of Windows was a disaster for gaming without DirectSound, DirectInput, DirectDraw, DirectPlay and the many changes we made to the Windows OS to enable fast input queues, non-pagable memory, fast CD-ROM loading, autoplay, direct access to VGA video modes, etc. That means that without DirectX Windows was still hopeless and unfixable by a third party for gaming. Since Microsoft had already done its monopoly OEM deals with all the major PC manufacturers the consumer market was getting Windows without DOS NO MATTER WHAT THEY WANTED. Apple had nothing and it’s own subsequent attempts at DirectX like API’s failed so it’s not likely that there was an alternative Universe in which they magically got it right. That left Japanese Consoles and their very proprietary 3D chips to dominate US gaming with the PC and Mac left to play Tetris. Thus given a relatively complete view of the game market in that era it is pretty clear that the range of alterative histories that produced a strong PC Gaming market and games like World of Warcraft were nearly zero. Microsoft was going to make it or break it unless you’re arguing that OS/2 would have swept the consumer PC market if Microsoft had broken DOS gaming?

          • I fully comprehend (and agree with) the point of your article. I’m addressing something else very specific you said in your comments. I acknowledge all that Microsoft did and the very real impact it’s had on the game industry. I appreciate the fact that no other established player with deep pockets at the time was interested in an open source media library like OpenGL.

            That changes nothing in the face of basic economic principle. You’re never going to convince me of this fatalistic philosophy of yours, that if Microsoft didn’t do it, no one else would have. Not when centuries of established trade has already proven you wrong. Not when open source was already well on its way to establishing a foothold in other even more prominent markets that continue to stymie even today’s Microsoft. Not when there were numerous commercial open-source-friendly vendors just on the horizon who were eminently willing and capable of making the exact same assessment Microsoft did, and fulfilling it.

            You say there weren’t many obvious avenues the PC gaming market could have taken. I contend that — obvious or not — all these things I’ve mentioned make the avenues limitless. You can pinch off as many avenues as you like in your reasoning six ways to Sunday. Your assessments in each case may even be correct up and down that line, but you will never come close to pinching off every avenue the PC gaming market could have taken. Neither does it negate the fact that erasing Direct3D from history would leave OpenGL as the only thing anywhere near what D3D accomplished, and that it was ripe for the picking by anyone with a shred of market savvy and the will to develop PC games in a post-DOS era.

            Now, one thing you can say (and have said) is that OpenGL owes it’s prominence in *today’s* Windows-dominated PC game market to Microsoft taking it under their wing in parallel with its game-friendly operating system and media library. That I won’t dispute.

          • “You’re never going to convince me of this fatalistic philosophy of yours, that if Microsoft didn’t do it, no one else would have.”
            Hang on, I’m not sharing a “philosophy” here, I’m pointing out that short of destroying Microsoft in 1995 nobody else COULD have saved the PC game market. They were a monopoly, they had total control, they had the power to kill any competition and DID, it took until 1998 and the DOJ to stop that. It’s not a theory because it’s the actual history that unfolded. I agree with you that the game market would just have flourished elsewhere, most likely on the PS/2 and Nintendo. To your point, there WERE other companies that DID TRY to make PC gaming work in that era. They either failed or Microsoft DID KILL THEM without a second thought. DirectX actually saved a few like Nvidia that were otherwise doomed.

            To your point, TODAY almost 20 years later the PC game market has indeed grown up around Microsoft’s dominance and become much more diverse and the paths of divergence are actually much fuzzier near the present than in that distant past because DirectX interacted with the modern market making it too complicated to predict how it would have played out otherwise… but in 1995 the range of market options was much more narrowly defined which makes the thought exercise… less theoretical in nature. The reason it’s interesting to explore is because Microsoft did not PLAN to make DirectX and actually broke PC and DOS gaming almost completely in Windows 95. So there is a “Schrodinger’s cat” moment in history when PC gaming was both decisively consigned to death and miraculously enabled at the same moment.

          • Yes, Microsoft had a monopoly. Yes, they squashed the competition in *every market they were interested in at the time*. This included games. Granted, these are historical facts. If you limit our mental exercise solely to 1995, you’re right, there’s no one who could have taken the PC game market and run with it the way Microsoft did, doubly so if you insist on saddling it with DirectX’s timetable.

            My argument is much broader than that. It’s predicated on what would have happened had Microsoft refused to make Windows game-friendly.

            Let me paint it a different way… Being robbed of DOS as a viable and supported platform for PC games caused an essential crisis for games on the PC, but it was far from death. Even with Microsoft dominating it, the PC remained an open platform that literally anyone could develop on without Microsoft’s approval or endorsement. As you yourself pointed out, this is exactly what many did, even though it meant certain defeat in the face of Microsoft’s ponderous shadow that was DirectX.

            My response to that is, imagine what they could have done without that shadow. Someone somewhere would surely have risen to the occasion. OpenGL was in prime position to do so, and there was nothing stopping literally anyone from taking it and running with it.

            In time, Microsoft was sure to notice what was happening, but there was nothing they could do about it but compete or acquire. But wait… that violates the predicate of this mental exercise. Microsoft can’t compete without making Windows game-friendly.

            You say Microsoft was in complete control. There’s a certain level of truth to that, but I prefer to peg Microsoft for the opportunist organization it’s always been. They got the game market as an artifact of convenience, because everyone already had Windows (or were fast becoming converts) for reasons that had noting to do with gaming, and because DirectX existed as the viable path of least resistance.

            That’s my take on it, anyway. Clearly, yours differs. That’s fine. I think lively debate is rapidly giving way to spinning our wheels at this point, and my boss is starting to give me the hairy eyeball with how much time I’m dedicating to it. 😉

            I want to thank you for your insights, though. I’m eager to read your future blog posts.

  3. One thought:

    If MS was SO influential as to force consumer GPU architecture… why it failed at modifying OpenGL to their needs?

    (Story paints OpenGL as lead by SGI, and then by MS after all)

  4. Here you go:

    static const char vs_src[] =
    “#version 440 core;\n”
    “layout (location = 0) in vec4 pos;”
    “layout (location = 1) in vec4 color;\n”
    “out vec4 vs_fs_color;\n”
    “void main(void) { vs_fs_color = color; gl_Position = pos; }”;
    static const char fs_src[] =
    “#version 440 core;\n”
    “layout (location = 0) out vec4 color;\n”
    “in vec4 vs_fs_color;\n”
    “void main(void) { color = vs_fs_color; }\n”;
    GLuint vs = glCreateShader(GL_VERTEX_SHADER);
    glShaderSource(vs, 1, &vs_src, NULL);
    GLuint fs = glCreateShader(GL_FRAGMENT_SHADER);
    glShaderSource(fs, 1, &fs_src, NULL);
    GLuint prog = glCreateProgram();
    glAttachShader(prog, vs);
    glAttachShader(prog, fs);
    static const float pos_colorData[] = {
    0.0f, 0.33f, 0.0f, 1.f,
    -0.33f, -0.33f, 0.0f, 1.f,
    0.33f, -0.33f, 0.0f, 1.f,
    1.f, 0.f, 0.f, 1.f,
    0.f, 1.f, 0.f, 1.f,
    0.f, 0.f, 1.f, 1.f,
    GLuint buf, vao;
    glGenBuffers(1, &buf);
    glGenVertexArrays(1, &vao);
    glBindBuffer(GL_ARRAY_BUFFER, buf);
    glBufferData(GL_ARRAY_BUFFER, sizeof(pos_colorData), pos_colorData, GL_STATIC_DRAW);
    glVertexAttribPointer(0, 4, GL_FLOAT, GL_FALSE, 0, NULL);
    glVertexAttribPointer(1, 4, GL_FLOAT, GL_FALSE, 0, (void*)(4 * sizeof(float) * 3);
    const float back[] = { 0.0f, 0.0f, 0.0f, 0.0f };
    glClearBufferfv(GL_BACK, 0, &black);
    glDrawArrays(GL_TRIANGLES, 0, 3);

    I make that 42 lines, including 11 lines of shader code for a grand total of 31 lines to clear the frame and a triangle (the Metal code does not include the shader). It assumes that a window and context has been set up and that someone else will call swap. Everything else is set up here. No frameworks, extensions or compatibility profile features could make this more concise are used.

  5. It’s hard for me to believe you had no idea what people wanted or that they intended to use OpenGL around 20 years ago..Here is an excerpt from a Mesa header from the same time period:
    (G)eneric Mesa interface:
    This generic interface to Mesa provides minimal functionality. It’s
    intended to be an _experimental_ interface for projects such as Linux/3-D
    hardware. There may eventually be many different implementations of this interface for different operating systems and graphics cards.
    * 1. #include
    * 2. use GMesaCreateContext() to get a new GMesa context
    * 3. use GMesaMakeCurrent() to activate a GMesa context
    * 4. do your OpenGL rendering
    * 5. use GMesaSwapBuffers() in double buffer mode to swap color buffers
    * 6. use GMesaDestroyContext() to destroy a GMesa context
    * 7. use GMesaGetContext() to return the current context

    Yeah, not much has changed and copyright is: Copyright (C) 1995-1997


    Drivers are written by people and so is software- no one cares about what these companies “want” to do. Maybe it’s time to get more interested in what other people are doing than what other companies are doing in relation to yourself?

    • Did I claim that I had “no idea” what people wanted 20 years ago? They specifically DIDN’T want OpenGL for gaming when I started work on DirectX in 1994, lacking any 3D API to start with I wanted OpenGL. It was better than nothing to start with. The stories in my blog are about the internal battles within Microsoft that prevented us from being able to use OpenGL and therefore led to the creation of Direct3D. Did you actually read this article? I’m showing Microsoft’s 1995 documentation for Direct3D 1.0 SHOWING support for OpenGL.

      uh… I don’t care about what other people are doing… I care about myself and I share what I know, what I’m doing and what I think on MY blog… I wouldn’t presume to speak for others, there are OTHER people’s blogs for that purpose. I’m not one of those bloggers who pretend to have any noble purpose other than to share my experiences and views.

  6. In 2001, I talked to the guy who did the CoreGraphics implementation at Apple
    before that he did DisplayPostscript at NeXT.
    He said Apple had DirectX running on CoreGraphics at their labs.
    He had no intention of releasing that.
    So if Apple’s intention was to clone Microsoft. They would have done it a decade
    NeXT had 3DKit which licenced RenderMan from Pixar were API was like SceneKit.

    I am sure you have studied the Metal Shading Language by now.
    It is C++11 which shading from GSLS and compute from OpenCL
    in one package.
    All the shaders are compiled ahead of time using LLVM.
    It is taking the LLVM bitcode and compile to machine code at runtime once.

    All of this will be in next version of OpenGL. I would bet money on it but I am poor.

    Another aspect of Metal is that it is shared memory so it is designed for
    integrated GPU. Which means death of entry and middle tier discrete GPU.
    That means NVidia.

    So far you have focused on Objective-C part which is just the
    setting up of the pipeline.

    So you focused on my comment about OpenGL being held hostage.
    The history you cited doesn’t make it not true that CAD company
    are not the one who wanted CoreProfile. CAD companies are not pushing for
    changes. if CAD companies were so great why didn’t they create OpenCL.

    So far you have copy and pasted Metal Code just to scare not to inform
    the benefit because you don’t know the benefit. and you have no intention
    to highlight the benefit.

    a former Microsoft employee on twitter basically said Metal, SceneKit and SpriteKit are so much better than anything from Microsoft in last 6 years.
    He said WPF is an embarrassment.

    PS. I can remember when Bill Gates said he would rather piss on NeXT
    rather than program for it. The was in 1990.

    • Let’s see if I can unravel some of this;
      1) I don’t think I suggested that Apple was trying to CLONE DirectX, I believe I suggested that Apple was trying to create a CLOSED PROPRIETARY 3D DRIVER API they control… like DirectX. Why would Apple WANT to clone DirectX? They want to own their own closed API’s obviously.
      2) Yes.. 3D hardware doesn’t change just because the API does… that does not make API’s that expose the same functionality IDENTICAL.
      3) I think I have been nothing but complimentary of Metal including attempting to associate my own BRILLIANCE 20 years ago with Metal’s recent architecture.
      4) How does showing that Metal’s 35 lines of code to draw a polygon compared to early Direct3D’s 220 lines SCARE anybody? Especially my readers who generally have IQ’s a little higher than your average JavaScript monkey.
      5) Yes I’m sure Apple’s plan in 2001 was to completely fail to compete in 3D API standards and cede leadership to Microsoft in that area… they were all about losing in graphics back then.

  7. Michael Pohoreski June 13, 2014 at 11:34 AM

    Gee, revisionist history much?!?! Why is it no surprise that this articles leaves out *several* KEY facts:

    * Funny how there is ZERO mention of Microsoft’s NIH syndrome and them buying RenderMorphics warping their Reality Lab API into DirectX. But I digress …

    * 3dfx jump started the PC gaming industry by providing inexpensive 60+ fps WITH texture mapping. For less then $500, here was a PC video card that could give a $20,000 SGI machine a run for money — it was disruptive technology, aka a game changer! A bunch of 3dfx people came directly from SGI.

    * The proprietary 3dfx Glide API provided A LOW level API to the graphics card. It *proved* you didn’t need an over-engineered API like Direct3D 2/3/5 to get high performance graphics.

    * glQuake was THE killer app for 3d graphics. John Carmack utilizing 3dfx’s “MiniGL” .dll proved OpenGL _could_ be used for real-time rendering.

    * There is NO mention of John Carmack comparing OpenGL and Direct3D: From his 11/23/96 .plan: ” It takes four times as much code to do anything in D3D as it does in OpenGL, but I will tune both to the best of my abilities and we shall see if there is any performance advantage to either API.”

    * The article claims “We thought game developers would adopt Immediate Mode” name dropping John Carmack. From his plan “OpenGL vs Direct-3D (Dec 23, 19966)”: “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.”

    * The success of 3dFX’s MiniGL help inspire nVidia’s OpenGL driver team to improve OpenGL support on their Riva TNT.

    * In both professional and amateur game developers *petitioned* Microsoft to *support* OpenGL instead of writing another over-engineered proprietary closed source 3D API. As usual Microsoft *ignored* developers.

    OpenGL “failed” _mostly_ because of Microsoft’s *politics* not only because of technical issues. To try to pretend that Microsoft was some “saint” is extremely misleading.

    • You haven’t actually read my blogs have you Michael? ALL of those stories and more are here. Even the story YOU are reading includes a link to early DirectX documentation that talks about the relationship between DirectX and OpenGL in 1995. I’m sure I know the history much better than anybody in the field and you would benefit from reading it.

      3DFX was doomed from the outset. The problem was that DOS was dead but in 1994 nobody had gotten that memo yet. Microsoft intended to kill it abruptly by force with the release of Windows 95 in the course of doing so BREAK DOS games and of course ALL glide games. The new Windows driver model and planned WHQL driver certification ensured that third parties could NOT create alternate driver layers for the Windows OS especially for the graphics subsystem. Had we not jacked Windows 95 for DirectX, it would not have been possible to write any kind of 3D driver for Windows that would have worked including Quake GL… running in Windows. With respect Michael, you have your history all wrong, but I’m here to educate people about how it really happened.

      As you point out.. Carmack STARTED using OpenGL in 1996. Rendermorphics was acquired and Direct3D was created in 1995. Carmack was working WITH MICROSOFT on Direct3D at that time. The port of DOOM to Windows in partnership with id was the first DirectX game ever made and the #1 best selling Windows 95 application ever published. Carmack didn’t like Microsoft or Windows in general (can’t blame him) so it didn’t matter what API Microsoft produced, Carmack wasn’t going to like it. Unlike ordinary game developers Carmack could afford to do something nobody else could do, which was force hardware vendors to write drivers JUST For his games. mini-GL was NOT OpenGL, it was just BrokenGL called something that sounded open-standardy but was largely useless to anybody but Carmack. He basically declared his own 3D driver model for HIS games.

      Nobody claimed Microsoft was any “saint” in all of this… again clearly you haven’t read the entire history on the subject POSTED PUBLICLY here on this blog. I tell all of the horrible inside stories about what happened with OpenGL.

      The things Carmack DID NOT like about Direct3D apart from it being ANY API FROM MICROSOFT was the COM Object model. It was a complex, convoluted mess that had one redeeming feature. It allowed Microsoft to rapidly evolve the D3D API without breaking backwards compatibility with games while OpenGL was forever shackled by the constraints of needing to preserve backwards compatibility with previous versions of the API at a time when 3D hardware was changing very rapidly. That lack of flexibility combined with lack of driver standards is what ensured that OpenGL remained BrokenGL for mainstream consumer applications.

      3DFX was never a factor, everybody including Nvidia knew that 3DFX wasn’t going to survive into the Windows dominated era because like Nvidia in the early days 3DFX did not accept that Microsoft was pulling the plug on DOS and that 3DFX would not have the power to carry a proprietary graphics API into a pure Windows world without playing ball with Microsoft. Nvidia nearly got killed by the same mistake but recovered quickly enough to survive by coming back to Microsoft and religiously adopting Direct3D support. (Those stories are here to)

      So spare me your nonsense about “KEY FACTS” you obviously don’t know what you’re talking about, weren’t there and didn’t bother to actually read the history you heard about somewhere documented on this blog. The history in retro-spect is very simple for anybody to understand. Microsoft was about to have a complete PC OS Monopoly, was going to dictate the driver models for PC computing and anybody who thought otherwise was going the way of the Dodo. There was going to be no OpenGL support on the PC from anybody that was not ALLOWED by Microsoft, because OpenGL was an API, NOT an OS hardware driver model and Microsoft was the only company in a position to define driver models for the Windows OS. Those are the indisputable facts, everything that transpired was just the futile machinations of people not realizing or accepting that Microsoft had already won total control of the PC desktop in that era.

      • Michael Pohoreski June 13, 2014 at 8:36 PM

        You certainly seem to making a lot of assumptions about me.

        1) I *was* _using_ Glide shortly after glQuake was released since it didn’t impose the overhead that D3D did. Glide was fast and simple.

        2) I never claimed MiniGL was a 100% full working OpenGL model. Everyone knew it was a limited sub-set. I even put the “mini” in quotations to draw attention to it.

        You are absolutely correct that Direct3D was “complex, convoluted mess”. Insert typical joke that Microsoft never gets anything right until the 3rd version. 🙂

        > “The things Carmack DID NOT like about Direct3D apart from it being ANY API FROM MICROSOFT was the COM Object model. ”

        Gee, let’s *also* ignore the *many* people that wanted Microsoft to support OpenGL as well. Let’s review some of the 53 people from the *first* petition:

        * Glen Corpse — wrote the rendering engine for Magic Carpet
        * Tim Sweeney — gee nobody important .. only wrote the core Epic’s Unreal engine; notably the software texture mapping using 2×2 dithering
        * Sean Barrett — wrote the software rendering engine for Thief 1
        * Casey Muratori — brilliant 3d programmer who wrote Granny and groks quaternions
        * Brian Hook — worked on Glide for 3dfx
        * John Miles — wrote the Miles audio library
        * Chris Hecker — worked at Microsoft, helped teach people how texture mapping worked. Wrote the famous “An Open Letter to Microsoft: Do the Right Thing for the 3D Game Industry” article for Game Developer.

        You’re telling me *all* these brilliant people were being delusional wanting a *proven* graphics API over an unproven one that was a “complex, convoluted mess” from Microsoft who had just bought the API from somebody else????

        The *second* petition had over 1400 people. I *signed* it. So don’t give me some high and mighty attitude about how I “weren’t there and didn’t bother to actually read the history you heard” when I *was* doing my part in making history then.

        Making excuses for how Direct3D was a complete cluster fuck in the early years isn’t going to cut it. Thankfully all that crap got cleaned up in D3D 7. (I ported a rendering engine from D3D5 to D3D7 back in the day.)

        Like I said, let’s ignore *KEY* parts of history.

        FOR the RECORD:

        I bought Windows 4.0 when it first came out and waited for Microsoft to officially support DirectX5 that Win95 did. That never happened. Having to use the unsupported DX5 “beta” from Windows 2000 gave me a clue on what Microsoft thought of 3rd party graphic developers.
        I bought Windows 2000 and waited for Microsoft to support DirectX8. That never happened.
        I bought Windows XP and waited for Microsoft to support DirectX10. That never happened.
        I bought Windows 7 and am waiting for Microsoft to support DirectX12. Want to take a guess on how that will turn out??

        Gee, I’m starting to notice a pattern here of Microsoft wanting me to pay using its “latest and greatest” API when OpenGL has worked on ALL the versions of Windows. Vendors can provide extensions via driver updates and I can try them out. /sarcasm: Thankfully Microsoft still refuses to ship en OpenGL.h header file that supports anything post 2.0+.

        This constant cycle to/from yet another proprietary graphics API promising “really fast bare metal, whoops it really is complicated” is getting tiring.

        OpenGL ES provides a standard cross platform API — something Microsoft isn’t interested in. I guess that is why D3D is such a superior API that it is used on iPhone, Android, Mac OSX, and Linux.

        How is Microsoft ignoring WebGL working out for IE again??

        • Dude, read the blogs. Glide was dead, it had no hope, it didn’t matter if it was better, none of it mattered once Microsoft turned off DOS and took over the driver architecture… Direct3D IM was a driver API designed to support OpenGL on consumer versions of Windows. It was COMified to deal with the rapid hardware evolution in the market. You’re welcome. Direct3D WON, totally won and swept the market. It hands down gave Windows total dominance over the PC game market exactly as it was DESIGNED to do in 1996. Game over. 20 years later Apple is making the same move to take control of its own platform and ditch OpenGL so they aren’t propping up BrokenGL ES in the mobile space.

          *Microsoft didn’t have to support DirectX on it’s latest OS versions BECAUSE of COM… see how that worked? If OpenGL works so great on Windows.. where are all the OpenGL Windows games? hmmmm….

          It’s all covered here, there’s no point in my repeating these stories in the comment section because you can’t be bothered to read the other articles.

          • They’re coming to cater to WinXP holdouts and pirates.

          • > If OpenGL works so great on Windows.. where are all the OpenGL Windows games?


          • You are aware that almost every single game on this list defaults to D3D on a PC. Of course they include an OGL renderer… what were they supposed to use to run on a Mac? Maybe .1% of the players of these games will ever bother to try to use the OGL renderer on a Windows machine.

          • Of the 133 games listed, 9 say they default to D3D. Even counting the ambiguous ones, that’s 26 games, that’s only 20% — hardly what I would call “almost every single game on the list.”

            Even if the list is woefully misleading in its annotations, that’s beside the point. Whether the players bother to try the OpenGL version is also beside the point. I was addressing your sweeping and unqualified question. If you want more, I can certainly go to item #2 in my Google search.

          • My POINT was that OpenGL games are a commercial failure on Windows PC’s because without Microsoft imposing tough driver stability standards they’re just BrokenGL games. Sure, PC game developers support OpenGL for portability to Apple.

          • Let me put all my cards on the table. I’m not an OpenGL fan, nor am I on any crusade to champion its cause. When it comes to the sum of its parts, my favor clearly lies with DirectX — if only it were multi-platform, I would likely have never head reason to give OpenGL a second glance.

            My only agenda here is to point out the fallacy of the question you posed.

            And excuse me, but Minecraft is in that list I referenced, Saint. I rather think I fitfully covered that base when I linked to it. So is Second Life, and a myriad of prominent titles that fit the same bill Minecraft does. I gave you the dinner plate, why are you insisting that I spoon-feed you from it?

          • Michael Pohoreski July 16, 2014 at 12:16 PM

            @Syndog why are you _still_ surprised that Saint John ignores OpenGL games like Minecraft?? One that just hit 54 million sales across all platforms. Minecraft has sold 12 million copies on Xbox360. 12 million / 54 million = 22% of the game is using D3D. Facts bursts his bubble that D3D isn’t all that.

            Saint has always been a Microsoft shill. If he wasn’t so drunk with the Microsoft Kool-Aid then us game devs who HAVE shipped multiple console games that _didn’t_ use D3D _might_ actual consider his revisionist history to be mildly interesting — instead of it being relegated to being a footnote.

            It is not just him. Microsoft pays lips service to “PC gaming” yet GFWL (Games For Windows Live) is equally hated by gamers everywhere.

          • Haven’t read much of my blog either have you Michael?

          • I know it is, that’s my point. It’s the only one that actually doesn’t run on Direct3D because it’s a Java game and you can see the support complaints littering their forums because of it. Minecraft is also an incredibly rudimentary 3D game, it’s about the lowest you can go in 3D capabilities that can reliably work on a broad spectrum of random OpenGL drivers without something blowing up. I think we can all agree that Second Life is NOBODY’s idea of a triple A of even successful game. I’m just trying to show you that the games that have chosen the pure OpenGL path have very primitive production values and it’s no coincidence. OpenGL is just a word that describes a random bag of inconsistent 3D features and it only works as an API when it is directly tied to a specific 3D hardware implementation such as a console or Apple chip in which the platform owner made it a priority to actually test the drivers and certify that they work correctly.

          • > My POINT was that OpenGL games are a commercial failure on Windows PC’s

            All I can say is, that’s a remarkable list of “failed” OpenGL games that don’t default to D3D on Windows.

          • They DO default to Direct3D on Windows… there is no installed OpenGL driver SHIPPED with Windows machines, they HAVE TO default to D3D. Do you think ANY of these games installs and fails without the user manually hunting down and installing a Windows OpenGL driver for the game on a PC? Think Syndog… think… does that make ANY sense to you?

            Here is the only reference to OpenGL in Microsoft’s WHQL driver standards guide for Windows.
            ” The following INF directives must be included in the INF:
             Feature Score – This is a General Installation setting that must be supported by all WDDM drivers.  
            Capability Override settings to disable OpenGL ”

            What that means is that Microsoft DOES NOT certify or ship OpenGL drivers with new Windows computers.

          • Saint… I’m doing my best to retain my detachment and civility here, but making an impassioned plea for me to think on an arguing a point you invented for the purposes of deflection does you absolutely no credit.

            You asked where the OpenGL games are for Windows. I considered the question to be a gauntlet fallaciously tossed on the ground, so I picked it up and answered your question by providing one list (among many lists) of OpenGL game titles for Windows. Immediately, you start qualifying your decidedly unqualified question by cherry-picking a subset of the titles listed, saying that “nearly every game listed” ran on D3D by default. Not exactly kosher of you after the fact, but hey, I’ll let you get away with it. I mean, what the hell… it’s your blog, right? If you say only titles that weren’t ported to or from D3D qualify as OpenGL games, that’s your prerogative.

            What I won’t let you get away with is saying that OpenGL is supported merely for compatibility on non-Windows platforms. If you rob OpenGL of its primary selling point — platform portability — then you’ve just disqualified every OpenGL game ever made. Sorry, that doesn’t fly for your argument.

            I also find it fascinating how quick you were to utterly dismiss the many and sundry successful games in that list that do, in fact, operate beautifully on Windows without any Direct3D at all. Are they all AAA titles? No, not even close. But again, that wasn’t a qualification of your original question, was it?

            Instead of admitting you made a fallacious error-in-fact, you doubled down by dragging the issue back onto Microsoft’s campus, made a blindingly axiomatic statement about D3D support, and begged me to think on it.

          • I’m sorry Syndog, you’ve managed to confuse me… which game on your OpenGL list for Windows does NOT default to Direct3D to run on installation? Since OpenGL support doesn’t ship with Windows computers, you’re claiming that somebody out there is making OpenGL games for Windows that don’t run on most Windows configurations… and that the people doing that are successful at it? I understand that you’re an OpenGL fan and don’t like the facts but all you have to do is name one hit game for Windows that won’t run on a Windows machine without an OpenGL driver. Just name that game and win the debate.

            Here’s a hint:

          • > It’s the only one that actually doesn’t run on Direct3D

            Saint, in all candor, the level of willful ignorance it takes to make that statement in the face of the facts is *staggering*.

            Why do you think I didn’t name any titles by name earlier? I knew you’d find a reason to dismiss them as irrelevant. Hell, you even laid out exactly how to “win the debate,” and *still* had the unfettered audacity to sweep aside your own criterion.

            I’ve tried to give you every benefit of the doubt that I could, but I’m not putting up with that, Saint. No self-respecting person would. This conversation is over.

            Good luck, man. I mean that sincerely and with love.

          • Dude, the only one being wilfully ignorant is YOU, I think I know pretty intimately how 3D works on the Windows operating system. If you actually wanted to LEARN how OpenGL interacts with Windows, you should be taking notes from me. There is no Windows support for OpenGL, there are ZERO games that run on Windows using OpenGL drivers “By default” because Windows has NO OPENGL driver model, there is only Direct3D. The games that claim to be OpenGL based are just API wrappers on Direct3D drivers on Windows. When Nvidia says that they make a unified Direct3D/OpenGL driver for Windows all they mean is that they have a Direct3D driver with OpenGL API bindings that aren’t tested or certified to work on Windows by Microsoft. Even when you get a game like Minecraft which has extremely limited 3D functionality running via JAVA JNI interface to an OpenGL binding… that OpenGL binding is still running on a Direct3D driver. It’s not that hard to grasp. I’m well aware that there are a whole lot of confused people in the world who don’t know the difference between an API layer and a driver layer. OpenGL is JUST an API layer, Direct3D is an API layer AND a driver layer for Windows… you can’t get HW accelerated 3D on Windows without using the Driect3D driver layer. Microsoft doesn’t ship or test OpenGL API bindings for Direct3D drivers which is why you constantly see support issues like this for games like Minecraft.

            The point is that OpenGL isn’t a standard for porting anything anywhere because the OpenGL API layer ALWAYS has to be mapped to some platforms proprietary graphics driver layer. In this example “Defaulting to OpenGL” for a Windows game just means “BROKEN ON WINDOWS BY DEFAULT”. On some platforms like Apple, the OpenGL API is the ONLY interface to the driver layer so the difference between the layers are indistinguishable to the developer. Apple is replacing OpenGL as their 3D driver interface in favour of Metal, a proprietary DirectX like driver API. You can be upset about that reality all you like, but it’s just the facts. Even games that claim to be “OpenGL” games on Apple will still have to write or adopt an OpenGL API implementation that pipes through the Metal driver API unless Apple provides one of their own (which seems likely). The reason for the driver API’s is that they will be faster and more efficient than a high level API so people who use OpenGL will trade some portability convenience for less performance and functionality.

            If you actually read the documents provided with my blog article instead of remaining “Willfully ignorant” you will see that the very first version of Direct3D was specified to work as an OpenGL driver layer EXACTLY as it does to this day 15 years later.

  8. Don’t forget Apple’s short-lived Game Sprockets API.

    Its dev team had the absolute coolest team jackets ever. The embroidery alone must have cost half the API development budget.

    • Ah, that’s funny, I HAD forgotten about it. Great quotes on the wiki about it;

      “As 3D games became widespread, the library’s Direct3D became a decisive advantage, and DirectX grew to become almost universal for PC gaming. By the mid-90s, gaming on the Mac was largely dead. The combination of high prices, stagnating sales, poor performance and a lack of a DirectX-like system all resulted in the game developers leaving the Mac field in droves. As it was in Microsoft, several Apple staffers took it upon themselves to redress this problem, led by Chris DeSalvo. The result was a two-pronged effort; on one side was the Game Sprockets libraries (along with RAVE), and on the other was a single target gaming platform, the Pippin”


Leave a Reply


Get every new post delivered to your Inbox

Join other followers:

%d bloggers like this: