That's probably a Brian Hook plan entry from around May 1999 when Q3Test was out and everyone didn't know their shit when it came to the concept of an OpenGL ICD that wasn't a MiniGL

leileilol wrote on 2025-08-29, 02:19:

That's probably a Brian Hook plan entry from around May 1999 when Q3Test was out and everyone didn't know their shit when it came to the concept of an OpenGL ICD that wasn't a MiniGL

I thought that too but then he said 3dfx dev so figured it probably wasn’t.

That particular plan was 9th May and can be found about half way down the page here https://www.bluesnews.com/cgi-bin/finger.pl?i … =19990512014751

Ah, yea, thanks, that was it. I misremembered where he was working at, although looking online it says he worked at 3dfx too at some point, so I don't know.

That blog doesn't seem to mention anything about glide though. I recall reading something about how glide isn't just an API but also the backend for communicating with the card, and that 3dfx hooked up OGL to the backend.

That was probably somewhere else. If you can find it please let me know.

Hmm, interestingly you're right. According to his website of the mid 2000's he was employee no.5 at 3dfx from 1995 to some point in 1996, by his own rough dates that means he was probably there 12-18 months. https://web.archive.org/web/20060427071806/ht … .com/about.html

Can't see anything obvious on that site about Glide being used for OpenGL though. The 3dfx article on Wikipedia says:

"The MiniGL translated OpenGL commands into Glide, and gave 3dfx the advantage as the sole consumer chip company to deliver a functional graphics library driver until 1998."
https://en.wikipedia.org/wiki/3dfx

That cites this book https://web.archive.org/web/20231113205249/ht … q=%22Mini-GL%22. However that only has:

"In 1997, John Carmack became disgusted with Direct3D, deeming it a “horribly broken API,” and began writing an OpenGL renderer for Quake. 3dfx responded by shipping a “mini-GL” driver for Voodoo-based accelerators that translated the 57 or so OpenGL commands used by GLQuake directly into Glide. No other consumer graphics chip company shipped a working GL driver until 1998, so 3dfx became the accelerator of choice for hard-core action gamers. "

But no real evidence for the claim. To be honest I expect the truth is probably more nuanced... a significant amount of the code for interacting with the hardware was probably shared between the driver implementations, perhaps by "glide" being buildable in two forms - a static library of functionality to be used by the different drivers and internal tools, with a separate DLL build (linked with the static library) for the public API (glide3.dll for example).

That would certainly be logical and wouldn't be unusual - the Kyro OpenGL driver used the PowerVR "glide equivalent" SGL2 library for all functionality bar rendering (albeit dynamically linked). I know the DX driver didn't (possibly because WHQL required drivers to be self contained?), but I wouldn't be surprised if some of the SGL2 hardware interfacing code was used. I haven't got the time or energy though to go looking in the driver source to check.

hornet1990 wrote on 2025-08-29, 21:10:

Can't see anything obvious on that site about Glide being used for OpenGL though

Yea, I didn't mean glide as the API interfaces themselves. When launching a glide game the 3dfx logo shows up, which doesn't for OpenGL, which perhaps could be considered an indicator of that.

hornet1990 wrote on 2025-08-29, 21:10:

"The MiniGL translated OpenGL commands into Glide, and gave 3dfx the advantage as the sole consumer chip company to deliver a functional graphics library driver until 1998."

I'm not absolutely 100% sure, but AFAICT that's not correct and is being constantly repeated by people without proper evidence, that it's just a wapper to glide. MiniGL seems to be still OpenGL but just a subset of it. Someone more knowledgeable can perhaps shed light on that.

hornet1990 wrote on 2025-08-29, 21:10:

But no real evidence for the claim. To be honest I expect the truth is probably more nuanced... a significant amount of the code for interacting with the hardware was probably shared between the driver implementations, perhaps by "glide" being buildable in two forms - a static library of functionality to be used by the different drivers and internal tools, with a separate DLL build (linked with the static library) for the public API (glide3.dll for example).

When launching an OpenGL game with a voodoo (well at least on voodoo 3), the glide3x.dll is loaded and the game fails without it. I don't remember the exact wording but it was along the lines of 3dfx having implemented both the Glide API calls and the backend/driver/whatever-the-correct-term-is that communicates with the card, within the glide DLLs. It seems they didn't want to write a full, separate implementation for OpenGL, so made it go through the backend within the glide DLL.

I'm not a programmer though, and certainly not one familiar with such low-level stuff, so might not be wording it correctly.

I'm interested to find that original source again, see if I could get more out of it or find some other sources based on that. It might've even been written by someone else, not sure.

hornet1990 wrote on 2025-08-29, 21:10:

I know the DX driver didn't (possibly because WHQL required drivers to be self contained?)

The same with voodoo. No glide dll with d3d games.

It does go through Glide to access the card. It gets all the device information from it (which card, tmus...), opengl does its thing, data is then prepared for glide and pushed to it and then glide sends it to the card.

Game->win gl api->openGl -> glide3->hardware

MiniGl as other said before, is just a subset, specifically made for a game, but not having full list of extensions, that would make it compliant with an OpenGl version.

eddman wrote on 2025-08-29, 21:42:

Yea, I didn't mean glide as the API interfaces themselves. When launching a glide game the 3dfx logo shows up, which doesn't for OpenGL, which perhaps could be considered an indicator of that.

That's just configuration... I'm sure they had a way of disabling that in code (see later)

eddman wrote on 2025-08-29, 21:42:

I'm not absolutely 100% sure, but AFAICT that's not correct and is being constantly repeated by people without proper evidence, that it's just a wapper to glide. MiniGL seems to be still OpenGL but just a subset of it. Someone more knowledgeable can perhaps shed light on that.

I had a quick look look and the 3dfx MiniGL is a full implementation of the public opengl32.dll exports, but when you decompile it in Ghidra most of the functions are empty and just return without doing anything. I always understood it to be a subset of an OpenGL ICDs functionality, as the above demonstrates. For example glVertex3d (for specifying a vertex position using 3 doubles) returns immediately, glVertex3f (3 floats) stores the provided value for later use.

The point of doing that though is that so long as the calling application only called the implemented functionality then it'd work. The game would be built using the opengl32.lib library as any other OpenGL application. The reason the mini GL is called opengl32.dll and placed in the executables folders is so that it is loaded (by the code in opengl32.lib) over the Microsoft implementation in the system32 folder that would then try to load an ICD. The Mini GL can then do whatever it wants - this is the basis for almost all wrappers.

eddman wrote on 2025-08-29, 21:42:

When launching an OpenGL game with a voodoo (well at least on voodoo 3), the glide3x.dll is loaded and the game fails without it. I don't remember the exact wording but it was along the lines of 3dfx having implemented both the Glide API calls and the backend/driver/whatever-the-correct-term-is that communicates with the card, within the glide DLLs. It seems they didn't want to write a full, separate implementation for OpenGL, so made it go through the backend within the glide DLL.

Not possible to go through the backend within the glide DLL. You can't call code within a DLL that hasn't been exported as part of the public interface... well, you could, but you'd need a method of exporting the function pointers to the using application and that doesn't appear to exist in the glide3x.dll exports as there is nothing there that isn't part of the public API. Of course I suppose it is possible that grGet could have undocumented parameters to return said function pointer array... but it doesn't appear to be so (see below)

If you look at this screenshot of the dependencies for 3dfxOGL.dll (i.e. their ICD) you can see it depends on glide3x.dll (so as you say if that's not present the OpenGL game won't run) and that only depends on windows libraries and ddraw.dll.

Looking at the decompilation in Ghidra of the ICD you can quite clearly see where it is calling the public API. For example this is from DllMain at process attahment that calls a number of internal functions before calling:

grGlideInit();
grEnable(8) ;

Now interestingly grEnable only publically accepts 5 values (GR _AA_ORDERED to GR_SHAMELESS_PLUG), defined as 1 to 5 in glide.h, so what does 8 do? Its not documented, but I'd put money on that being part of the "don't show the splashscreen" mechanism or a "this is OpenGL so configure accordingly" call.

Picking any glide function shows similar call graphs from internal code to grWhatever, including grDrawTriangle. There's no magic - they're just using the public API and to be honest who could blame them? They were probably in a rush to develop the ICD to combat nVidia et al so it makes sense to use the public glide API and keep just the one codebase to maintain for actually talking to the hardware.

eddman wrote on 2025-08-29, 21:42:

I'm not a programmer though, and certainly not one familiar with such low-level stuff, so might not be wording it correctly.

That's always the problem with these kinds of discussions as you never quite know how in-depth someones knowledge is. I've got a pretty good understanding of fairly low level stuff but there's always people who know far more than me. It's also been 20+ years since I last worked at that sort of level...

eddman wrote on 2025-08-29, 21:42:

I'm interested to find that original source again, see if I could get more out of it or find some other sources based on that. It might've even been written by someone else, not sure.

TBH all the evidence you need is in the ICD's dependencies and decompiled code (see above)

Ugh, now you've got me going down a rabbit hole! 😁

Decompiling glide3x.dll and grEnable supports the values 1 to 8. What 6 & 7 d0 would be something to experiement with... all value 8 does is set 3 memory locations to the value 1, one of which is undoubtedly the "don't show the splashscreen" flag.

Yea, not knowing the technicalities makes it difficult to discuss it. I can perhaps ask it this way. The basic, public understanding of a "rendering API wrapper", say a Direc3D-to-Vulkan one, is that it translates a certain interface/function of one to the equivalent one from the other.

Is that what's happening with 3dfx's OpenGL solution? That it simply translates the OpenGL interface calls a game makes to the equivalent Glide ones? If so, then all of it is just a big API wrapper, not much different from something like DXVK or d3d8to9, I presume.

hornet1990 wrote on Yesterday, 10:29:

TBH all the evidence you need is in the ICD's dependencies and decompiled code (see above)

Now I want to find the original source even more, because your findings contradict it. I do recall the writer separating Glide's functionalities into two distinct parts. I want to see if there is something I missed or maybe just misunderstood.

eddman wrote on Yesterday, 12:22:

Yea, not knowing the technicalities makes it difficult to discuss it. I can perhaps ask it this way. The basic, public understanding of a "rendering API wrapper", say a Direc3D-to-Vulkan one, is that it translates a certain interface/function of one to the equivalent one from the other.

Is that what's happening with 3dfx's OpenGL solution? That it simply translates the OpenGL interface calls a game makes to the equivalent Glide ones? If so, then all of it is just a big API wrapper, not much different from something like DXVK or d3d8to9, I presume.

Arguably yes. However OpenGL is a much higher level API than Glide so there is a lot more going on around state management etc than just mapping one command to another. For a start you need to implement a full TnL pipeline before you even get to the point of rendering triangles, which is essentially the level Glide was at. You'd need to implement all areas of OpenGL to be conformant in the ICD too, even if some of that was software fallbacks or very slow in hardware. You had to support it, it didn't have to be fast to pass, especially for lesser used functionality such as accumulation buffers.

D3D by comparison with its feature flags allows a much more direct mapping of functionality to glide and just report what you do actually support.

eddman wrote on Yesterday, 12:22:

Now I want to want the original source even more, because your findings contradict it. I do recall the writer separating Glide's functionalities into two distinct parts. I want to see if there is something I missed or maybe just misunderstood.

That's why I suggested that one part could have been a common static library that handles all the interfacing with the hardware which is then used by the ICD and Glide DLL. That could still be true since we've not considered the D3D driver which as we know is self contained, but it just wasn't used directly for the ICD (preferring to go via Glide3x.dll instead). There may have been reasons for doing that... developer familiarity, development speed esp. given the amount of other functionality that needed implementing as mentioned above etc.

hornet1990 wrote on Yesterday, 13:20:

That's why I suggested that one part could have been a common static library that handles all the interfacing with the hardware which is then used by the ICD and Glide DLL. That could still be true since we've not considered the D3D driver which as we know is self contained, but it just wasn't used directly for the ICD (preferring to go via Glide3x.dll instead).

That's basically what was written there, that OpenGL is hooked up to that static library and talks to the card through that, that it doesn't get converted to Glide rendering calls but, unless I'm still understanding it wrong, you say it'd still have to go through that part of Glide too.

What he said: 3dfx OGL ICD -> Glide static library -> card
What I get from this discussion: 3dfx OGL ICD -> Glide API rendering interfaces/functions -> Glide static library -> card

At this point the original needs to be found, since it could be saying exactly what you said and I simply didn't understand it correctly. Man I should've bookmarked it. 🤪

How long ago did you see it? Could it still be in your browsers history?

That was probably 2-3 years ago, if not more.

I know i've had to make a post here at least once explaining that GLQuake isn't a Glide game before (probably for some 'glide games list').