Kernel-based dithering of BSP surface lighting (in software)

[mankrip]

[mh]

I'm wondering at this stage if there's better mileage in just biting the bullet and writing a 32-bit software renderer?

One theoretical way of doing this is by drawing 3 views - one for each of the R, G and B channels - to offscreen buffers, then combining them during write-out to the back buffer. You'd need 3 copies of each colormap, again one for each of R, G and B, but that's a lot more lightweight than lots of huge LUTs. An optimization would be to run the vertex transforms and Z test once only, then only the actual drawing runs 3 times. You could even reuse the original ASM code for much of this.

[mankrip]

Well, this algorithm is blazing fast. The only change for each texel is using (light + XY0a) (or (light + XY0b)) instead of light. It should be quite slower than the x86 ASM version, but someone with enough skills could port it to Abrash's code.

But the main point for me is that it keeps the original colors. In the screens I've posted, notice how the darker parts of the wall goes a bit cyan, and then goes somewhat between green and brown before going fully black.

To me, this is part of Quake's visual identity. In the software renderer, the darkest spots of the game are actually very rich with all those different and somewhat unexpected colors showing up in the shading. It gives a better sense of the ravaged, desolated places where the player goes, because the darker it is, the more chaotic it gets. This is the same reason why I like this kind of filtering in PrBoom's software renderer, and always wanted to do the same in Quake.

In hardware-accelerated engines, the shading looks too clean, too perfect, and that makes the atmosphere more bland.

However, I often think about how to implement colored lighting, and it's a case where I agree that 24 or 32 bit color should be better. Maps with colored lighting are almost always made for hardware-accelerated engines, so using true color rendering for them is the best to make them look as their authors intended.

About your ideas for optimization, the easiest way for doing that would be to switch the surface cache and virtual screen buffer for each color before calling the function to draw the spans. But since the dithered versions of those functions are in C, it would be more appropriate to convert them to 32-bit, using 32-bit surface caches.

[Spike]

32bit surface caches rock, although depending on surface caches means you're stuck with 'nearest' filtering (including dithered nearest sampling).
you can do linear sampling with or without a surface cache - it just looks terrible in 8bit, and slow in 24+bit.

[leileilol]