As I understand it...

3dfxvgl.dll = Voodoo Graphics / Voodoo2 OpenGL standalone driver, Glide3. Windows does not go through this, as it is not a primary video device and therefore a game must explicitly use it (such as Quake3 and MDK2).

3dfxogl.dll = Banshee OpenGL ICD, Voodoo3/4/5 OpenGL ICD, Glide3. For these video cards, it is defined in the registry and Windows will use it (like every other OpenGL-supporting video card of the time)

3dfxgl.dll = 3dfx MiniGL driver as used by Quake2/Half-Life games, Voodoo Graphics/Voodoo2, Glide2. Supported games also must explictly use this driver. This driver does not ship with the 3dfx video drivers as supported games provided specific versions of them. As a mini driver, it's not fully GL 1.1 compliant. Originally created as a quick stopgap to get GLQuake working on 3dfx in early 1997.

Voodoo Graphics and Voodoo2 are 3d accelerators that are limited by being a secondary video device adapted from targeting arcades, and can't do 3d in a window, hardware cursors, 512x384 minimum etc. so support for them are specialized. Banshee and Voodoo3/4/5 are proper video cards.

leileilol, thanks a lot!
Maybe you also happen to know why 3dfxogl.dll and 3dfxvgl.dll export not only ICD functions (those with the Drv* prefix) but also the full set of opengl32.dll and WGL ones?
I've noticed some mentions of a thing called "Windows standalone OpenGL driver", is this it? And what was the rationale for such a design, compared to a conventional ICD?

It's "standalone" because you could have a 3dfx Voodoo Graphics / Voodoo2 card installed alongside another host video card that's capable of OpenGL and it's a way to avoid conflicts with like a TNT or a Rage 128, etc. Also, non-game desktop apps that use OpenGL can't work with 3dfxvgl.dll anyway because you can't render Voodoo Graphics / Voodoo2 in a window on the host video card (there were third-party DLL attempts at reading the buffer to make this 'possible' but they're very slow).

Both 3dfxvgl.dll and 3dfxogl.dll should be equally conformant to OpenGL 1.1.

You may also want to read up on Brian Hook's 1999 planfile as he took the brunt of getting OpenGL driver support going for 3dfx then during Quake3's early public testing period of May 1999. There were *a lot* of clarifications. At the very bottom (May 9, 1999) there's an official explanation about the distinction of a standalone driver, an ICD driver, and a mini driver.

leileilol wrote on 2024-07-09, 17:00:

It's "standalone" because you could have a 3dfx Voodoo Graphics / Voodoo2 card installed alongside another host video card that's capable of OpenGL and it's a way to avoid conflicts with like a TNT or a Rage 128, etc. Also, non-game desktop apps that use OpenGL can't work with 3dfxvgl.dll anyway because you can't render Voodoo Graphics / Voodoo2 in a window on the host video card (there were third-party DLL attempts at reading the buffer to make this 'possible' but they're very slow).

Both 3dfxvgl.dll and 3dfxogl.dll should be equally conformant to OpenGL 1.1.

Oookay, but then I have a reverse question: why then 3dfxvgl.dll also exposes an ICD interface if it's a freestanding implementation and not an ICD? It provides a lot of exported functions with Drv* prefixes that comply with the ICD specification.

leileilol wrote on 2024-07-09, 17:00:

You may also want to read up on Brian Hook's 1999 planfile as he took the brunt of getting OpenGL driver support going for 3dfx then during Quake3's early public testing period of May 1999. There were *a lot* of clarifications. At the very bottom (May 9, 1999) there's an official explanation about the distinction of a standalone driver, an ICD driver, and a mini driver.

Nice. I already came across this page when I previously found complaint reports (one, two) about Wolfenstein: Enemy Territory not working, with logs containing the line "assuming '3dfxvgl' is a standalone driver". Luckily, this game is open-source (and based on the Quake III Arena, which is open-source too), so I was able to figure out what it really meant.

BlackDoomer wrote on 2024-07-11, 08:29:

Oookay, but then I have a reverse question: why then 3dfxvgl.dll also exposes an ICD interface if it's a freestanding implementation and not an ICD? It provides a lot of exported functions with Drv* prefixes that comply with the ICD specification.

Why not? All it then takes is a handful of registry entries to turn it into an ICD…

The codebase for an ICD is not small and yes, you could add some compile time directives to exclude the Drv functions but that adds to the complexity of the codebase and means you need to compile it twice (ICD and standalone), verses compiling once and shipping the dll regardless of whether those functions will ever get called or not (like pretty much every dll ever)

The only benefit of removing them would be saving a few hundred kilobytes at most on the customers hard drive and I’m pretty sure no one has ever complained about the size of an OpenGL dll!

BlackDoomer wrote on 2024-07-11, 08:29:

Oookay, but then I have a reverse question: why then 3dfxvgl.dll also exposes an ICD interface if it's a freestanding implementation and not an ICD? It provides a lot of exported functions with Drv* prefixes that comply with the ICD specification.

From my testing with my Voodoo 1, if you want to force the utilisation of 3dfxvgl.dll you just need to copy it into a game folder as opengl32.dll and it will work. I've tested this with using a Tseng ET6000 to ensure that there was a clear difference between the Microsoft software ICD and the Voodoo ICD.

Not like it really matters, the Voodoo ICDs has some of the worst OpenGL compatibility I've seen - only the SiS6326 ICDs are worse, as the Java beta ICD for the SiS6326 is the only 9x ICD I've come across that identifies as OpenGL 1.0-compliant rather than 1.1, and the ICD that comes with the AOpen driver provides invalid OpenGL 1270-compliance according to Minetest, while AIDA64 believes that it's 1.5-compliant.