Hacker News new | ask | show | jobs
by kevingadd 1228 days ago
Arguably without the OpenGL vs D3D and now Vulkan vs D3D back and forths, along with experimental APIs like MANTLE, we definitely wouldn't have a lot of the robust tech we have access to today.

OpenGL's freeform experimentation and evolution with extensions let people test things out in production environments to figure out what worked, while D3D's stable feature set meant that games and productivity software could - if it made sense for the developer - choose to ship a more limited feature set that worked everywhere, all of the time.

D3D also has consistently offered great debugging tools and a robust reference rasterizer, things you simply can't get in an OpenGL environment. As a game developer it's invaluable to be able to swap over to a Direct3D backend for debugging even if you end up using OpenGL as your default. (These days, Vulkan has first-class debugging support too, which is great.)

Now we have Vulkan as the new home for experimentation and it has great debugging and validation layers, while D3D pushes forward on certain new features and provides a more consistent baseline on Windows desktops. For console games as well, you can use Vulkan on (AFAIK) Nintendo Switch, while using D3D12 on Xbox, so each API is providing value for console game devs as well.

2 comments

> OpenGL's freeform experimentation and evolution with extensions let people test things out in production environments to figure out what worked

Yeah, except nobody did this. The cutting-edge features came to Direct3D first because Microsoft had early access to what the GPU vendors were doing and could plan out what that would look like from an API perspective. The vendor extensions only came out around the same time as the DirectX support, maybe later. Core OpenGL support would onlu emerge years later.

> As a game developer it's invaluable to be able to swap over to a Direct3D backend for debugging even if you end up using OpenGL as your default.

What? Name a game developer who's done this in the past 20 years -- use Direct3D for debugging and OpenGL as the default. Only Id Software actually used OpenGL and Vulkan seriously, and they are owned by Microsoft now so that will change.

> Name a game developer who's done this in the past 20 years

I'd imagine it was really popular among console developers, who would usually develop two versions of their game anyways (a DirectX one for Xbox/PC and an agnostic one for Mac/Playstation/other). DirectX is traditionally considered easier to use (and comes with PC tooling) so I could see how people would prefer it for debugging.

Contrary to urban myths OpenGL was never a thing in most game consoles.

Sony only supported it on PS 2, and quickly moved into LibGNM(X) as almost no one cared, Nintendo had a OpenGL like API on the Wii, and while the Switch supports GL 4.6/Vulkan, its main API is NVN.

IIRC there was an OpenGL layer for PS3, but it was terrible and I only know of one (indie) dev who shipped a full-blown game on it. It was an awful experience from my understanding.
Before Vulkan, if you wanted to do graphics debugging like step-through on pixel shaders, your options were Direct3D + PIX or, if you had access to them, game console dev tools. Maybe Apple had something?

Obviously, lots of games only had an OpenGL backend. So those devs simply didn't have access to those tools. It's the one outlier API with bad tooling.

See Instruments for macOS, and tooling from GPU vendors.

The main problem with Khronos APIs has always been "go fishing" attitude, Vulkan isn't much better, even with the LunarG SDK.

Isn't DX 11 the same as OpenGL 1.1 whereas DX12 is OpenGL 1.2?

Edit, I might be mixing up OpenCL 1.1/1.2

DX11 is like modern OpenGL, DX12 like Vulkan.

(OpenGL 1.x/2.x is ancient, and comparable to DX8/9. All still used by old software, though.)

I still recall oh so many OpenGL apps failed to start when OpenGL 2.0 was released, as 1.x had been around for so long "everyone" had gotten used to just checking the minor version number.