Do you happen to know a fruity HW company that today runs it's own proprietary graphics API when the open Vulkan or OpenGL exist? /s

All jokes aside, back then it made sense why every 3D HW company was baking their own API. It wasn't just for gatekeeping/rent seeking, but the consumer 3D graphics acceleration business was brand new, there was no standardization, so nobody knew where the future was heading, so they wanted to have full control over it as they built it. Plus, they were shipping hardware before Microsoft had come up with DirectX so they needed some API until then, and I assume they were afraid to touch OpenGL, the API of their biggest competitor.

Yeah, but how many AAA games use it exclusively? Every AAA game I know of is either using Vulkan, OpenGL, or DirectX directly, or they're using a game engine like Unity or Unreal and abstracting away the graphics API.

You forgot the Playstation (LibGNM/LibGNMX) and Nintendo ones (depending on the generation, microcoded GPU, GX (Wii), GX2 (WiiU), NVN (the main one on the Switch), Vulkan and GL 4.6).

No, it's not. What a silly thing to say.

Is the developer writing Metal code? No. Then they're not using it directly. They're using an abstraction.

"using it directly" means the developer is writing Metal code themselves. Writing Unity code that eventually gets compiled to Metal is not writing Metal any more than writing C that gets compiled into machine code means you're writing machine code.

Think of it this way...if someone wants to hire an experienced Metal developer for a Mac-exclusive game, do you think someone who's only developed using a game engine like Unity would be qualified?

> You forgot the Playstation (LibGNM/LibGNMX) and Nintendo ones (depending on the generation, microcoded GPU, GX (Wii), GX2 (WiiU), NVN (the main one on the Switch), Vulkan and GL 4.6).

Irrelevant to the conversation. We can talk about developing with proprietary APIs and continue to just use Apple's Metal as an example without bringing up all the other proprietary APIs. Not sure why you think I "forgot" all the other APIs.

If networking protocols were managed the same way as ARB and then Khronos do their work, we would only have the RFC for the IP layer, and then lots of extensions to choose from for the upper layers and traffic monitoring from each networking card vendor.

(By today's standards, those famous early 3D games were laggy crap, both hardware- and software-rendered, on many/most period-correct computers. It's rarely said that simple things like texture interpolation (computationally way too much for a CPU) were new, and impressed people more than fps counters. Yes, the vaseline polygons were once the look of the Future!)

Then two companies leveraged their positions to change that course. First was Microsoft, which really needed everyone to start using system-wide multimedia APIs instead of dozens of unmanageable DOS era bypasses offered by this or that hardware manufacturer. So Direct3D was introduced, and then quickly remade in a numbers of later versions to match the breakneck progress in hardware features (or directly wrap around them, if you wish). On one hand, it was a universal API, on the other, people would still write “ATi code” and “Nvidia code” years later.

The other was id Software, though not in a straightforward way. Quake I was ported to accelerated hardware (vQuake, glQuake). Partially because of vQuake experience, Quake II compartmentalized the renderer into a library, and only that library was supposed to be written with the help of hardware makers (or by them). Ironically, OpenGL support was more of a tech demo thing because id Software had the expensive professional hardware, and regular users obviously didn't, despite the calls to support that API in consumer 3D accelerators. Even more ironically, 3dfx decided to make a bare minimum OpenGL wrapper library for Glide to let already existing glQuake run on Voodoo instead of trying to make some deal on the porting. They called it MiniGL. Soon other manufacturers, game makers, and people trying to make this or that existing software work on consumer PCs followed the example, and the world saw a lot of custom hacked "opengl32.dll" semi-implementations tightly coupled to respective applications. Of course, if any of them happened to be copied into system directory, everything but the specific software running with specific hardware that library was supposed to support crashed or broke. Those who tried to write new programs by the book using these wrappers probably had some problems, too.

Then Microsoft was forced to act, even though it never really intended to support alternatives to DirectX family. It made OpenGL (standardized) an official system-wide API, but made the system library to be just a wrapper over complete OpenGL implementation provided by hardware manufacturer (if present). So it continues to this day, and making everything work properly has been AMD/Nvidia's problem, not Microsoft's. This is why people on Windows can still choose between OpenGL and Direct3D in game settings, and see something on screen using both. But when it all got started both were just thinner or thicker wrappers over what chip designers initially had in mind.

In other words, by the time 3dfx had a product out the door, Direct3D already existed. The fight over proprietary APIs should have been over and Glide should not have existed. DirectX 5, which greatly matured the Direct3D API, came out in August 1997, less than a year after the Voodoo, and still 6 months before the Voodoo 2. Glide should have been dead by then.

[0] https://en.wikipedia.org/wiki/Direct3D#Direct3D_2.0_and_3.0

[1] https://en.wikipedia.org/wiki/3dfx_Interactive#Products

"Carmack: Direct3D is now better than OpenGL"

https://www.bit-tech.net/news/gaming/pc/carmack-directx-bett...

Another bit of history, before DirectX, during the days of Win32s extensions for 16 bit Windows there was WinG library, which provided an accelerated framebuffer.

https://en.wikipedia.org/wiki/WinG