Colored lighting faithful to the original colormap?

[mankrip]

The main reason why I never implemented colored lighting is because I don't want the engine to lose this:

See how the mono lighting makes the walls go from beige to purple, to blue, and to green before going fully black?

It would be easy to blend that lighting with a single colored light, but if multiple colored lights with different colors intersect each other (e.g. a blue light from the quad and a red light from a rocket) and also with a mono light (usually from the BSP's lightmap), I couldn't think of a good way to preserve the color artifacts of the colormap while gradually blending it with the multiple colors of the colored lights.

Any ideas?

[Spike]

if you're staying 8-bit, the palette is too useless to do coloured lighting (though you might be able to get away with it with dithering, but thats ugly in its own right).

if you want to retain the discolouration, you could probably achieve that by applying some non-linear distortion of the input lightmaps. increase green values at the low end and boost red at the highish end.

or just ask yourself if discoloured banding is really what you like seeing...

if you're doing direct-to-rgb rendering (ie: paletted texture, rgb framebuffer), just do the colormap[lightmap][texture] lookup 3 times per pixel? you'll get the same result for white lights while low green lights will be brighter than low red lights. plus you'll still have the hideous banding thing (although yes, you may get 3 times as much banding as each light channel starts to band at a different point, but as making it ugly appears to be your goal this is somewhat of a moot point and may actually help image quality much like dithering does)...

[mankrip]

[mankrip]

Probably a good way to achieve what I'm after is to blend all the lights, calculate the intensity of the resulting saturation, calculate the hue banding inversely proportional to the intensity of the saturation and scaled to the hue banding of the colormap, and apply the resulting banding to the hue of the lighting.

[leileilol]

This is why I chose to use a big 18-bit translation table (generated using the same BestColor function that made the colormap). Remember that 8-bit color (in VGA) only has 18-bit color precision, anything more than that is a waste. You'd probably have to do something about BuildLightmapRGB halving precision. Note that Engoo shifts the lightmap a tiny bit brighter to avoid artifacts, so that might have also affected the banding

[mankrip]

[Baker]

I think what was meant by the VGA compatibility is essentially DOSBox compatibility, which should be VGA as far as I know (did they have 16-bit color DOS games ever in the late 90s?).

(And has the nicety of being able on any platform that supports DOSBox which is almost everything)

[qbism]

[revelator]

depends how late in the 1990's cards like the S3 virge and tseng labs 4000 did have more than 16 bit color
(actually they could both handle 32 bit color but they where so slow that they could not handle a game at that colorsetting).
there where also vesa cards able to run games at 256 color depths.

have a look here

[r00k]

[leileilol]

Probably could recreate it in GLQuake by linearly resampling the lightmap upward x 16, nearest filtering AND palettizing it to the Quake palette

[mankrip]