They were 3dfx hardware enabled features. Even the contemporary NVIDIA gear predating the GeForce 256 lacked paletted textures and only supported table fog through emulation.

Table fog makes a visual difference in stuff as late as Thief II (2000).

Final Fantasy VII (1998) refused to enable D3D acceleration if paletted textures weren't supported, but the requirement was soon patched out. I believe it mostly amounts to a performance feature.

Thank you for that response. It led to me searching for things a little differently and I stumbled upon a partial list of titles where table fog (which I now understand to be the mechanism by which fog is rendered - duh) is actually a really big deal. The list I found (so far):

* Centipede
* Rainbow Six: Rogue Spear
* Test Drive 5 (patch 1.1)
* Thief II: The Metal Age
* Shadows of the Empire

I'm still not 100% clear on what paletted or palettized textures actually are... though it is definitely helpful to know of at least one game that requires them for hardware acceleration.

Palleted textures are common practice to save memory with little loss in color quality, mostly used on early 3D game consoles up to PS2. And 3dfx have arcade hardware roots.

rob8086 wrote:

Thank you for that response. It led to me searching for things a little differently and I stumbled upon a partial list of titles […]
Show full quote

Thank you for that response. It led to me searching for things a little differently and I stumbled upon a partial list of titles where table fog (which I now understand to be the mechanism by which fog is rendered - duh) is actually a really big deal. The list I found (so far):

* Centipede
* Rainbow Six: Rogue Spear
* Test Drive 5 (patch 1.1)
* Thief II: The Metal Age
* Shadows of the Empire

I'm still not 100% clear on what paletted or palettized textures actually are... though it is definitely helpful to know of at least one game that requires them for hardware acceleration.

A paletted texture is a texture that uses 256 colours (or even less, the famous model 2 arcades could use even 2 colour textures) selected from a total of 64K (16 bits) or 16M (32 bits) colours.
They're used to save space and in their time they were also faster to render; even the PS2 uses a lot of paletted textures, and sometimes the PC ports of these games also uses them, causing graphical glitches in modern hardware.

Awesome! Thank you, appreciate the mini-lesson.

So it sounds like it's mostly ports that would require paletted texture support. Considering how many titles that could cover (Mortal Kombat, GTA, Tony Hawk, FF off the top of my head), that seems pretty important!

I think there was a similar thread somewhat recently in which people tried to find games that required paletted texture support. Aside from FF VII and VIII, it was only really a couple of other games that had issues, so you're probably not missing much. Table fog support however was more widespread and it can lead to a lot of games looking very bland without it. Shadows of the Empire is the classic example that comes to mind.

firage wrote:

They were 3dfx hardware enabled features. Even the contemporary NVIDIA gear predating the GeForce 256 lacked paletted textures and only supported table fog through emulation.

Table fog makes a visual difference in stuff as late as Thief II (2000).

Final Fantasy VII (1998) refused to enable D3D acceleration if paletted textures weren't supported, but the requirement was soon patched out. I believe it mostly amounts to a performance feature.

Is fog emulation anything more than an additional pass over the framebuffer?

You can think of an 8-bit paletted texture as a simple, non-animated gif image, and a video card as a bitmap editor: if the bitmap editor does not natively support these lightweight images that come bundled with their own color palette, they will be automatically converted to 24-bit before they can be touched any further.

Problem is, going from 8-bit to 24-bit adds 2 bytes to each pixel, making the image much bigger and thus a greater amount of memory is required in order for them to be processed.

Put another way, a video card that supports paletted textures doesn't need to convert smaller, 8-bit textures to 24-bits therefore less video memory is required.

But that's not all there's to it. If the paletted texture does have transparency, it can't just be converted to 24-bit because there's no place where to slap the transparency information back into the picture, which could be easily resolved by going 32-bit instead (the extra byte being the alpha channel that replaces the transparency in the 8-bit texture), or coming up with a custom texture format or God knows what else, but as it turns out, a workaround, elegant or not, hasn't been available since the GeForce FX, and anything afterwards will not handle paletted textures correctly, leaving you with nasty, black outlines that totally destroy the edge of the sprites, sprites which are generally handled as any other texture at the lowest level.

Oh, wow. Thank you for that explanation. After reading this, I have like... zero interest in another ATI build. Haha

Well going 24-bit/32-bit wasn't really an option for most paletted textures in their heyday combined with the APIs and the common 3d cards then. Most games took the RGBA4444/RGB565 approach with significant color precision loss (though some argued back then 16-bit textures meant higher quality)

DosDaddy wrote:

But that's not all there's to it. If the paletted texture does have transparency, it can't just be converted to 24-bit because there's no place where to slap the transparency information back into the picture,.

It's trivial to convert to 32-bit RGBA while reading a chroma key index.... it's exactly what GLQuake does for the menus and sprites.

So now that we know the possibility on how widespread 8-bit palleted textures are, I'm guessing that either the method on how it was handled changed somewhere between DirectX 5 and 6 or the cards that explicitly lack support for it (e.g. Radeons and Geforce 6xxx+) render them as 24/32-bit textures (or both)?

I'm not to worried about table fog, I did the registry patch to re-activate it on my Radeon 7200 and I can see fog in the weather effects in Monster Truck Madness 2 (assuming that game uses table fog). If by the off-chance I see a need to use an nVidia card instead, I'll be sure to secure a Geforce3 or 4Ti for my parts collection just in case (old parts won't stay in the market forever, you know).

It seems that a voodoo1 in a faster systems (>400Mhz) has problems with the "8-bit Paletted Textures" in Direct3D, in Glide they are stille fine.
It can be checked with a voodoo1 in forsaken when changing from RGBA to "8Bit paletted". Mageslayer, Motoracer do have that issue in d3d.

Here is an explanation of table fog, also known as pixel fog: https://docs.microsoft.com/en-us/windows/desk … p/direct3d9/fog
In short, it was a simple trick, relatively cheap to implement in fixed-function hardware, to convert the depth of a pixel to a 'fog factor', and use a table to blend the pixel colour to get an illusion of fog.
Since the fog implementation is driver-dependent, the results may vary from one video card to the next.

The feature has been superceded by pixel shaders, where a detailed fog effect can be coded directly, in a driver-independent way.

firage wrote:

Even the contemporary NVIDIA gear predating the GeForce 256 ... only supported table fog through emulation.

Correct. The RIVA 128, RIVA128ZX, and the RIVA TNT used vertex fog to emulate table fog until the GeForce 256, which supported table fog in hardware. This Nvidia white paper will tell you more.

It would hard be to overstate the utility for retro gamers of a visual feature list for games, accompanied by a hardware list of visual capabilities for applicable APIs.

W Gruffydd wrote:

It would hard be to overstate the utility for retro gamers of a visual feature list for games, accompanied by a hardware list of visual capabilities for applicable APIs.

I agree.

So, if I understand correctly, Radeon cards are a no-go as none in any generation supported these features?
As for nVidia, the best cards for legacy compatibility sound like Geforce 256 to the Geforce 4 range.

Is this right?

Does the entire 3dfx lineup support these features natively?

Early Radeons can do table fog with a registry tweak. They didn't officially support it. Radeon R100-RV280 can definitely do it. No palettized texturing though.

GeForce cards prior to GF4 have ugly S3TC/DXT1 due to a lack of dithering with it. The GF4 Ti is great for compatibility with a lot of D3D and OpenGL games. The GeForce FX cards are nice too, except 5700 is too new to run the more compatible driver 45.23.

So, if the FX series is the latest series to fully support these features, would the NV38GL based Quadro FX 1300 be useful since it is both very fast (for an FX card) and also PCI-E based? Would make for an interesting card to drop into a PCI-E system for full compatibility with nearly everything made before 2004 or so. I know it uses a bridge chip though, so that could cause issues with later boards.

How would driver support be for a card like that? How about with a modded .INF?

W Gruffydd wrote:

It would hard be to overstate the utility for retro gamers of a visual feature list for games, accompanied by a hardware list of visual capabilities for applicable APIs.

Tests like:

- a single 16 gray texel scaled up and modulated up, to expose filter precision
- a basic room with colored mip levels to show the standard lod calculation and bias
- some really additive-blended overdraw of a dark texel to bring out the 16-bit color dithering matrix
- Some 1x1, 2x2, 4x4, 8x8 and 16x16 textures for testing the minimum texture sizes allowed
- Some rectangle texture tests to see if those are allowed
- Texture clamping modes
- a reminder that no 3d card is perfect in any of these results and they are purely subjective tastes

I remember that X-Wing Alliance been working fine till my FX5900XT. Once i replaced it with 6600GT i got scrambled mostly unreadable text in missions. Later Nvidia cards had same issues. Not sure it source of problem is the same....