As a teenager/young adult in the late 90s/early 00s, I was so glad to see 3dfx fail. I hated how popular the Glide API was since you could only run it on a 3dfx card. I had asked for a 3dfx Voodoo for Christmas one year, and my dad got me a Rendition Verite 2200. It supposedly had better performance than a Voodoo while having a lower price, but it couldn't run Glide, so couldn't play half the games I wanted a Voodoo for.
I didn't want to feel ungrateful to my dad, so my frustration got targeted to 3dfx for making a proprietary API when OpenGL and Direct3D existed.
I eventually got a Voodoo Banshee, but by that time Glide was falling out of favor.
>my frustration got targeted to 3dfx for making a proprietary API when OpenGL and Direct3D existed
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.
To be honest, I can't think of anything that's actually exclusive to the fruity company's graphics API? I mean, they have no game market to begin with.
> 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
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.
Abstracting away the graphics API and using the one native to each platform is using it directly.
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).
> Abstracting away the graphics API and using the one native to each platform is using it directly.
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.
I also know a couple of game console vendors with their own proprietary 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.
I think you're retrofitting the common clichés about proprietary APIs into your memories. First (circa 1995) 3D accelerators were all different and incompatible with each other: NV1 was using Saturn hardware (and only got used in some Saturn ports), 3D Rage had its own API (creatively named CIF, from “C interface”), S3 Virge had its own API (S3D), Vérité had its own API (RRedline), Voodoo had its own API (Glide). Interoperability wasn't even discussed; when (some) games added support for (some of) those, it usually was a completely rewritten executable, i. e. port to that graphical architecture. The main difference between those accelerators was that the former targeted fillrates of top consoles of previous years, still hanging on early nineties 3D vision (a couple of low poly models; fake perspective, like in racing games; mix of 3D and 2D sprites and backgrounds; z-buffer? you can simply draw polygons in proper order!), while the latter competed with professional accelerators (in fillrate, not in shading capabilities), and made a breakthrough.
(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.
The first version of Direct3D shipped in DirectX 2.0 (June 2, 1996) and DirectX 3.0 (September 26, 1996) [0], but the 3dfx Voodoo came out in October 1996 [1].
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.
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.
There was a strong pro-OpenGL faction at Microsoft. Their goal was to support ports of Unix OpenGl apps to Windows NT. That the resulting OpenGL driver also supported 3D games was mostly an unintended side effect.
As a teenager/young adult in the late 90s/early 00s, I was so glad to see 3dfx fail. I hated how popular the Glide API was since you could only run it on a 3dfx card. I had asked for a 3dfx Voodoo for Christmas one year, and my dad got me a Rendition Verite 2200. It supposedly had better performance than a Voodoo while having a lower price, but it couldn't run Glide, so couldn't play half the games I wanted a Voodoo for.
I didn't want to feel ungrateful to my dad, so my frustration got targeted to 3dfx for making a proprietary API when OpenGL and Direct3D existed.
I eventually got a Voodoo Banshee, but by that time Glide was falling out of favor.