TGA Palette Support, and Palette Format Considerations (Patreon)

TGA palette support was already implemented, now I just need to test it.

The only feature still missing in the TGA palette support is intermediary color generation, for palettes generated from TGAs without enough colors to fill the palette. For example, if a 24-bit color TGA image's pixels has only 16 colors, the other 238 colors in the palette must be generated by the engine. The generated colors must be intermediary colors, to help with smoothing out the color blending effects, but I also need to take into consideration the colors necessary for the color shading table, which is used by the lighting. The general idea is that you should be able to, for example, get some tiles and their corresponding 16-color palette from a Master System or SNES game, import them into Retroquad, and create 3D environments with proper lighting and semitransparency effects.

Intermediary color generation is also important to optimize standard 256-color palettes. Vanilla Quake itself has 12 duplicated colors, 11 of which are in the same range (non-fullbright) and 1 in different ranges:

• 0, 48

• 16, 175

• 32, 223

• 51, 80

• 52, 81

• 53, 82

• 76 (non-fullbright), 247 (fullbright)

• 111, 192

• 112, 207

• 141, 157

• 142, 158

• 143, 159

If the engine replaced most of those duplicated colors with the intermediary colors of the most inaccurate color blending pairs, the quality of the compiled textures, compiled mipmaps and color blending&lighting effects would increase a lot.

There's a notable exception, which is the colors (0, 48) pair. In operational systems such as Windows, the colors zero (full black) and 255 (full white) of the video palette can't be changed. This means that for vanilla Quake's palette, we can't replace the color 48 with an intermediary color, because since the color zero doesn't support palette tinting effects (e.g. underwater screen tinting), the engine must use the color 48 in all cases where the color zero would otherwise be used. Retroquad already does this, by automatically replacing all instances of the color zero with the color most similar to it (in Quake's palette, index 48) when loading non-recompiled assets.

The color index 255 is a similar case, not only due to that system palette limitation, but also because it's a color index used for colormasked transparencies in the engine. This means that in practice, the maximum number of unique colors supported by any software-rendered 8-bit indexed color engines (not just Quake engine derivatives) is 254.

So far, in the vanilla Quake's palette, this leaves us with (12 - 1 = 11) duplicated colors that we could replace with intermediary colors. But there's yet another weird case. The colors 76 and 247, despite being identical, are in different color shading ranges. In vanilla Quake, while the color 76 can receive lighting & shadows, the color 247 can't. In theory, this makes it impossible to replace one of those colors with an intermediary color without affecting the lighting, but Retroquad also supports glow/luma maps which are independent of color shading ranges (textures with glow/luma maps can use all 254 colors in both their shaded diffuse underlay and their fullbright overlay), so we can safely replace the vanilla Quake's color 247 with an intermediary color if all textures have their fullbright colors converted into glow/luma maps.

This also means that to achieve that, Retroquad must drop support for rendering non-recompiled textures, and always use recompiled internal textures instead. This is not an issue, since at the non-mipmapped level, the recompiled internal textures looks identical to their vanilla sources. In fact, in the option "Texture type" of the video options menu, both the "Unfiltered" and "Filtered" settings uses recompiled internal textures instead of vanilla internal textures, so you can already see that.

Another reason for dropping support for rendering non-recompiled textures is that if we're going to replace the duplicate colors with intermediary colors, all textures will have to be modified upon loading anyway.

And finally, in vanilla Quake's palette, despite the color index 255 being used for colormasking, its RGB values are a unique shade of brown not present in the rest of the palette, and this caused the issue of many user-made textures using it for opaque texels because the vanilla Quake engine doesn't support transparent texels in BSP textures. This is a valid reason why most Quake engines only supports transparent texels in BSP textures with the "{" character in the name. This is kinda a can of worms to fix, and one way to properly fix that in Retroquad may be to replace that color index in fully opaque BSP textures with the color index of one of the duplicated colors, and copying the RGB values of the color 255 to the new index. This reduces yet another color from the color indexes that could be used for intermediary colors, resulting in (12 - 1 - 1 = 10) colors.