Texture Colorization and Palette Cycling Plans

Before working on generating intermediary colors as mentioned in the previous post, I'm going to work on implementing texture colorization and palette cycling.

Texture colorization is what vanilla Quake does to the player's skin when customizing the shirt and pants colors, and there are several ways to achieve that. Vanilla Quake's software renderer does that by creating a modified color shading map for players, and GLQuake's hardware renderer does that by creating a copy of the player's skin with the color indexes modified in the skin itself.

Some custom hardware-accelerated engines with support for replacement textures in 24-bit color achieves texture colorization of such textures in a third way, by employing brightness maps which are combined with the hue and saturation of the chosen colors. Those brightness maps are usually placed in files named player_0_shirt (player model, skin zero, shirt's texels) and player_0_pants (player model, skin zero, pants' texels). I'm thinking of using a similar method in Retroquad, because it's the method most compatible with Retroquad's quadricolor format. This way, each subcolor in the quadricolor of each colorized texel won't be restricted by specific color ranges, so the colorization can be really smooth. This method is a little slower than the methods employed by WinQuake and GLQuake, but it's more scalable than the GLQuake method and the performance impact will be the same as in the glow/luma maps, which is really small.

Right now, Retroquad doesn't support pants/shirt colorization of external textures at all, and this is how it'll be fixed.

However, there's still another issue related to color mapping. In the 90s, it was a common practice for indexed color games to use a technique called "color cycling" to animate several textures at once without creating new animation frames in the textures. In good hands, palette cycling is a powerful tool to create rich animations with a tiny memory footprint. But colorized brightmaps aren't suited for palette cycling, because the brightness levels are static and the hue and saturation is the same for the entire brightness map.

I wish there was a way to use a single solution for both texture colorization and palette cycling, because otherwise the rasterizer will get even more complex. I don't know if there's a way to combine both, but I feel it's possible, so I'm going to study the possibilities.