For these two games i would say Glide is not only faster and has the same level of image quality. The only thing you lose is being in True 32bit mode.

Trank wrote:

For these two games i would say Glide is not only faster and has the same level of image quality. The only thing you lose is being in True 32bit mode.

I always had the feeling that in Glide beside the impressive frame rate boost, quality seems to lack something.. like the depth of colors and brightness, just like something was missing compared to other accelerations. Same feeling I had in Half Life (Q1 engine) comparing D3D,OGL and Glide subset.

Neither Quake (nor its derivatives) used Glide. There is no "vs." here.

and most visual comparisons are usually associated with the high default gamma and/or undither post-filter, which is not necessarily API specific

Oh true, its actually just another version of opengl.

leileilol wrote:

Neither Quake (nor its derivatives) used Glide. There is no "vs." here.

and most visual comparisons are usually associated with the high default gamma and/or undither post-filter, which is not necessarily API specific

I always thought both games used different opengl dlls just to point to the internal glide calls. Wasn't it callign also glide2x.dll?

Yea the game doesn't actually use Glide 😀

A subset of OpenGL, required to run the game, is translated to Glide. That's what MiniGL does. But because of the 3dfx origins, it does so very well with OpenGL stuff and that's why 3dfx cards are very fast here, despite using this translation / wrapper.

There are various MiniGL files you can try, especially there is one that works really well on K6 CPUs with 3DNow!

PhilsComputerLab wrote:

Yea the game doesn't actually use Glide 😀

A subset of OpenGL, required to run the game, is translated with MiniGL. But because of the 3dfx Origins, it does so very well and that's why 3dfx cards are very fast, despite using this translation / wrapper.

There are various MiniGL files you can try, especially there is one that works really well on K6 CPUs with 3DNow!

I imagine Glide api being so similar if not a subset of Opengl that the translator actually had no costs in term of performance. But internally the hardware used the translated Glide calls from the Minigl? So basically it was Glide drivers running the game? 😁
I remember the wonderful 3dnow! version and the even more impressing frame rate boost. Something that still nowdays make me think about the combinations of K6-2 cpu and Voodoo could have done (more) back in days.

if glide is more low level than opengl i cant tell really, but my first thought would be no - this had to be implemented by 3rd parties for the whole glide thing to influence the market;
certainly opengl with time gained a technological upperhand on glide - new functions were added while glide stood more or less the same (v5 era);
also on weakly home pcs glide may run a lot faster than a full opengl implementation - less code may give more speed; the same may be true on the hardware side;

386SX wrote:

I remember the wonderful 3dnow! version and the even more impressing frame rate boost. Something that still nowdays make me think about the combinations of K6-2 cpu and Voodoo could have done (more) back in days.

Yes, on a K6-2 or 3, I don't think there is anything that runs Quake 2 as fast as a Voodoo card. That is with the right drivers.

Isnt Glide just a cut-down version of OpenGL with some features (ones unsupported by 3dfx hardware) removed?

I assume thats the reason why those games run so well, despite having to translate instructions.

Munx wrote:

Isnt Glide just a cut-down version of OpenGL with some features (ones unsupported by 3dfx hardware) removed?

I assume thats the reason why those games run so well, despite having to translate instructions.

That's what I remember too and I remember reading somewhere they cutted it down to optimize it entirely in hardware (beside I don't know what could differ from a usual opengl hardware implementation by another manufacturer).
I imagine that in the GLQuake case, probably not every Opengl calls were used and probably not even Glide ones. So I imagine that we can talk about a native Glide game the ones that is written specifically for 3dfx "100% Glide" api.

Munx wrote:

Isnt Glide just a cut-down version of OpenGL with some features (ones unsupported by 3dfx hardware) removed?

Not really.
You can see the main API in this file: http://glide.cvs.sourceforge.net/viewvc/glide … e.h?view=markup
It doesn't use the state-machine/stack approach that OpenGL uses. Most important difference is that it works entirely in screen-space, and no transforms are done whatsoever. These are left to the application.
This implies that you can also implement an OpenGL-ish state machine and transform pipeline on top of Glide easily.

Scali wrote:

Not really. You can see the main API in this file: http://glide.cvs.sourceforge.net/viewvc/glide … e.h?view=markup It doesn't us […]
Show full quote

Munx wrote:

Isnt Glide just a cut-down version of OpenGL with some features (ones unsupported by 3dfx hardware) removed?

Not really.
You can see the main API in this file: http://glide.cvs.sourceforge.net/viewvc/glide … e.h?view=markup
It doesn't use the state-machine/stack approach that OpenGL uses. Most important difference is that it works entirely in screen-space, and no transforms are done whatsoever. These are left to the application.
This implies that you can also implement an OpenGL-ish state machine and transform pipeline on top of Glide easily.

Basically miniGL quake did this in top of Glide? Unreal was a "real" Glide game then?

386SX wrote:

I imagine that in the GLQuake case, probably not every Opengl calls were used and probably not even Glide ones. So I imagine that we can talk about a native Glide game the ones that is written specifically for 3dfx "100% Glide" api.

Not entirely.
Support for OpenGL was not available yet on consumer hardware when GLQuake was launched. 3dfx was one of the first with a 'MiniGL' driver, which was basically a minimal implementation of OpenGL, solely written to run GLQuake (which was the only OpenGL game available for Windows at the time).
GLQuake was actually developed on SGI systems, and then ported to Windows. At the time, only professional 3d accelerators had OpenGL support, and even then, it was often flaky. So when developing and optimizing GLQuake, the developers were careful to avoid functionality that wasn't implemented in hardware (OpenGL had the annoying characteristic that all functionality MUST be supported by the driver, which means that if the hardware doesn't support it, it needs to implement a slow software rendering path as fallback). But even so, performance and support were limited.

See the GLQuake readme:

Theoretically, glquake will run on any compliant OpenGL that supports the texture objects extensions, but unless it is very powe […]
Show full quote

Theoretically, glquake will run on any compliant OpenGL that supports the
texture objects extensions, but unless it is very powerfull hardware that
accelerates everything needed, the game play will not be acceptable. If it
has to go through any software emulation paths, the performance will likely
by well under one frame per second.

At this time (march ’97), the only standard opengl hardware that can play
glquake reasonably is an intergraph realizm, which is a VERY expensive card.
3dlabs has been improving their performance significantly, but with the
available drivers it still isn’t good enough to play. Some of the current
3dlabs drivers for glint and permedia baords can also crash NT when exiting
from a full screen run, so I don’t recommend running glquake on 3dlabs
hardware.

3dfx has provided an opengl32.dll that implements everything glquake needs,
but it is not a full opengl implementation. Other opengl applications are
very unlikely to work with it, so consider it basically a “glquake driver”.

(what they refer to at the end as a "glquake driver" is what's become known as MiniGL)

386SX wrote:

Basically miniGL quake did this in top of Glide?

Yes, GLQuake was a 'regular' OpenGL application. It didn't use Glide directly. Which is why GLQuake still runs today, on modern hardware with 'regular' OpenGL.
3dfx' MiniGL was a wrapper from the OpenGL subset that Quake used, to Glide (which is why you needed the Glide DLLs to run the game on 3dfx).

386SX wrote:

Unreal was a "real" Glide game then?

Yes, Unreal had multiple rendering backends, including an OpenGL and a Glide one. There are various other games that used Glide directly.

Scali wrote:

Yes, GLQuake was a 'regular' OpenGL application. It didn't use Glide directly. Which is why GLQuake still runs today, on modern […]
Show full quote

386SX wrote:

Basically miniGL quake did this in top of Glide?

Yes, GLQuake was a 'regular' OpenGL application. It didn't use Glide directly. Which is why GLQuake still runs today, on modern hardware with 'regular' OpenGL.
3dfx' MiniGL was a wrapper from the OpenGL subset that Quake used, to Glide (which is why you needed the Glide DLLs to run the game on 3dfx).

386SX wrote:

Unreal was a "real" Glide game then?

Yes, Unreal had multiple rendering backends, including an OpenGL and a Glide one. There are various other games that used Glide directly.

Thank, I never thought the miniGL as a -wrapper- even back in the days. Speaking of the GLQuake, the "unofficial" opengl32.dll for the S3 VIrge did the same thing for the Direct3D or the calls were done directly to the hw features? (beside the 4/5/fps it moved 😁)

386SX wrote:

Thank, I never thought the miniGL as a -wrapper- even back in the days. Speaking of the GLQuake, the "unofficial" opengl32.dll for the S3 VIrge did the same thing for the Direct3D or the calls were done directly to the hw features? (beside the 4/5/fps it moved 😁)

I would think that S3 would wrap to their internal driver API directly, rather than translating to Direct3D.
I know PowerVR remapped OpenGL to PowerSGL in their MiniGL drivers.

Scali wrote:

386SX wrote:

Thank, I never thought the miniGL as a -wrapper- even back in the days. Speaking of the GLQuake, the "unofficial" opengl32.dll for the S3 VIrge did the same thing for the Direct3D or the calls were done directly to the hw features? (beside the 4/5/fps it moved 😁)

I would think that S3 would wrap to their internal driver API directly, rather than translating to Direct3D.
I know PowerVR remapped OpenGL to PowerSGL in their MiniGL drivers.

The Powervr results with the PCX2 are interesting indeed even if probably lacked something in the translation. The S3 Virge is already a miracle to see accelerate such a complex game.

the "3dfx-opengl" was only a glide-wrapper for opengl, or am I wrong?