===============================================================================
dgVoodoo 2.71.3: Glide related stuffs

===============================================================================

Table of contents

1. Glide options
2. Glide additional options
3. Gamma correction
4. Some technical info
5. Napalm build
6. Tips and known issues

===============================================================================

1. Glide options


2. Glide additional options


3. Gamma correction

A gamma correction curve can be set through the Glide interface. Since Glide uses a linear curve by default it might not match the default or one's taste and can look ugly (at least in the old days, I remember it looked ugly on CRTs). For the standard see sRGB on google.

That's why the CPL has the 'Enable Glide gammaramp' option: you can disable the curve coming from Glide and let your monitor use the default.

*As taking a closer look into this, I realized that a linear curve is used by the nowadays adapters by default but they probably post-calibrate it according to the sRGB standard. So Glide's linear curve won't change anything to wrong. I'm little confused about this. Back in the old days my real problem could be that either brightness of my CRT was too high by default or sRGB was not followed by the adapters therefore some gamma-adjusting game had really bad (pale and really bright) look. I do not know it by now but won't remove the possibility of disabling Glide gamma ramp. Test it on your monitor.

Color adjustments are supported in both fullscreen and windowed mode however brightness is always calculated into the gamma ramp curve in fullscreen so it has effect only if your adapter supports setting up gamma curves.


4. Some technical info

Unfortunately Glide cannot be implemented in practice as a standalone API which is completely independent on the underlying hardware. If someone looks through the Glide SDK then it is clear that this API is suited for the 3Dfx Voodoo hardware and its registers. However there are rules even in Glide (as in other APIs too) that must be observed in respect of driving the API. An application should never assume anything about the hardware being driven even if it knows what hardware it is driving. The application should get all the info from the API and keep the driving rules.

However in practice there are some application violating those rules very hard. Since Glide provides free direct access to the frame buffer it is typical to utilize the properties of a real 3Dfx hardware connected to the PCI bus. For example, writing to the frame buffer while it was requested to lock for reading, swapping buffers while one/some of the buffers are locked and assuming that the mapped pointers of buffers remains unchanged, using 2048 bytes as frame buffer stride, or drawing simultaneously by the 3D hardware and LFB writes through the PCI bus even when a buffer was locked with idle 3D hardware mode. Most of them can be workarounded easily but there is one case which can cause performance drop if emulated perfectly. This case is the mentioned simultaneous writing. dgVoodoo can emulate this usecase but you must enable it explicitly so I reluctantly inserted an option into the CPL, named 'Force emulating true PCI access'. This is the only technical option related to the quality of the implementation. There are only a few games it should be used for (see 'Tips') so it would be a pity to have it pointlessly enabled for the rest.

There is another strange option in the CPL, namely 'Pointcast Palette driver build'. Well, early 3Dfx hardware allowed separate texture palettes/ncc tables for each TMU so this possibility was reflected in Glide 2.11 and 2.43. However, latter 3Dfx hardware used a unified memory model meaning that only one global palette/ncc could be set for all the TMUs. Glide3 don't even allow to set them in any other way. The funny thing is that original Glide2 drivers internally also forced the global palette/ncc thing despite the API allowed separate ones. It was because of pushing the programmers towards the future hardware. But, maybe there were drivers built for custom vendors with the capability of separate tables. So if this option is enabled in the CPL then such a driver build is emulated but it has effect only on non-UMA cards. I don't think that any Glide application in the world requests such a driver build so always keep this option disabled. It just makes the appearance wrong if more than one TMU are used. This option is only for the sake of fullness.

dgVoodoo exposes the following Glide capabilities according to the selected card type:

Card typeFBI revisionTMU revisionGlide3 extensionsUMA
? (unexposable via dgVoodoo)0x00010x0000-no
Voodoo Graphics (SST-1)0x00020x0001GETGAMMAno
Voodoo Rush (SST-96)0x00020x0001GETGAMMA, CHROMARANGEno
Voodoo 20x00020x0001GETGAMMA, CHROMARANGE, TEXMIRROR, PALETTE6666no
Voodoo Banshee0x10020x1001GETGAMMA, CHROMARANGE, TEXMIRROR, PALETTE6666, TEXUMA, TEXTUREBUFFERyes
Other (greater)0x1000030x100002GETGAMMA, CHROMARANGE, TEXMIRROR, PALETTE6666, TEXUMA, TEXTUREBUFFER, FOGCOORD, TEXCHROMA, *PIXEXT, *COMBINE, *TEXFMT, *SURFACE, *GETREGISTRYyes
* Available in Napalm build only

5. Napalm build

Why is a separate build needed for Napalm? Why not just use it as a plain Glide3 implementation in general? Well, the answer is about the performance, again. Napalm has a bit more complicated shaders in order to handle Voodoo4 features like extended combine modes, 32 bit rendering, 32 bit texture formats and big textures. So, it would be wasting of GPU resources to use it with Glide3 applications not requiring these features (that is, all apps except Project64, in practice :) ).

Note that there is no significant difference between Glide3 and Glide3 Napalm as for performance if dynamic shader compiling is enabled. In both cases, much more optimal shaders are compiled and used than the precompiled ones.
Some limitiations:

Don't forget to set card type to 'Other (greater)' with 2 TMUs in the CPL to emulate a Voodoo4.


6. Tips and known issues