When I saw Doom 2016 running on OpenGL I was shocked. I would’ve never thought you could write an AAA game with it. It made me wonder why game developers use DX instead.
If you want to target Xbox, you need to write a D3D renderer anyway (although the Xbox API has some significant differences, if I understand correctly). There's little point writing an OpenGL renderer if your target platforms are Windows, Xbox, and PlayStation (which has its own graphics API).
Also, my understanding is that on Windows, OpenGL generally runs into more issues with driver bugs than D3D does.
I work for a large video games company and we usually write two backends - DirectX for Windows and Xbox, and a special one for PlayStation. That is changing slightly with Stadia, because that forces us to write a Vulkan renderer too. But on the few games that have it, the DX12 performance is better on windows than that of the Vulkan renderer backend - so we haven't released it to the public.
> Also, my understanding is that on Windows, OpenGL generally runs into more issues with driver bugs than D3D does.
I'm not sure if that's the case anymore, but it definitely has a bad rep on Windows. Initially (throughout XP and maybe some of Vista) OpenGL support on Windows was done by a OpenGL -> DirectX translation layer, so performance was always worse in OpenGL mode unless a game's Direct3D implementation was especially awful. This stopped being the case when NVIDIA started shipping a full OpenGL driver. (I'm not sure when AMD/ATI started shipping theirs)
> Initially (throughout XP and maybe some of Vista) OpenGL support on Windows was done by a OpenGL
Initially (Windows 95), OpenGL support was provided directly by the OS. Starting with Windows 98, Microsoft stopped updating the OGL version of their reference driver, so users were stuck with OGL 1.1 unless the graphics card driver shipped with a custom OpenGL implementation.
So whenever an application uses an OGL version higher than v1.1, it is provided by the graphics card driver and that has nothing to do with DirectX. There is no translation layer in that case (unless of course, that's what the driver does internally, but that's up to the manufacturer).
TL;DR Custom OGL drivers shipped with every graphics card that supported OGL in Windows since 1998.
That hasn't been the case, then, because I clearly remember OpenGL being translates to DirectX in XP/Vista days. Whether it was because anything >1.1 called that up or because the driver vendors chose translation over native, I don't know.
Original link seems to be dead but Slashdot references Vista layering OpenGL on top of Direct3D:
That comment references something else entirely - namely the Aero rendering system of the OS. This didn't affect applications that didn't use the Aero glass scheme (it was an option during window creation), however, or apps running in full-screen mode.
The Aero glass scheme was hardware accelerated and only worked with Direct3D, thus any OGL context created for a window using this renderer would have to run via Direct3D.
This is a very special case and as noted earlier, easily circumvented by simply not using this feature in your app.
Because game developers mostly don't pick the backend, game engine developers do. The vast majority of game developers pick a game engine and that drives most of their other technical decisions. There are really only a dozen game engines that have enough market share to matter, and a decent chunk of the biggest ones were built on top of DX for various reasons. OpenGL, while a great concept, was a fairly flawed execution for quite a while (its gotten a lot better in the last 10 years or so), so I can at least partially understand why in the past someone who doesn't care at all about cross-platform support might have steered clear of it.
Also, my understanding is that on Windows, OpenGL generally runs into more issues with driver bugs than D3D does.