Indexed colored .lit concept for software engines

[qbism]

Indexed .lit idea for software engines: A lit file that stores colored light as 8-bit palette indexes rather than RGB colors. Let's call it a "pal-lit" !

The goal is to apply color completely through 8-bit look-up tables without ever expanding a palette color to RGB.

If the engine can't find a pal-lit file, it looks for a standard lit file and palettizes it, converting each 24-bit RGB to 8-bit using BestColor function.

A 256x256 table is created to look up result of lighting color index vs. texture color index. I'm guessing overbright should be taken into account with this table.

Could be extended to include indexed color dynamic lights?

[leileilol]

I don't know. Quake has 15 color ramps, it's essentially colorizing all models to that color ramp. Very low lighting precision will make it look BUILDish

[Spike]

you still need to blend textures with lightmaps.
you still ought to smooth light levels across surfaces (not using gl_nearest on lightmaps, in gl terms)
not sure you truely gain anything

additionally, if you're using the palette for lightmaps, all that will happen is the world becomes even more brown! :P
as leilei says, a gradiant only has 16 descrete values, you'd end up with noticable steps along walls and stuff.

If you make your own file types, you need to make a tool to generate them somehow, using lits means that you can just get people to use existing tools.
an additional downside is that either you end up with an extra file, or you get gl users complaining that they don't get coloured lighting.

Sorry, but I only see disadvantages.

[mankrip]

Indexed-color LIT files would require different tools to generate it, and would require a specific indexed palette, so they wouldn't work properly when switching palettes.

Instead of changing the file format, you could just convert the RGB LIT files to indexed colors upon loading.

[qbism]

To get any kind of light smoothness, each colored light should be aligned to a color band on the palette. Even so, maybe not enough color interpolation.

A standard lit could be loaded and translated without creating a new lit format, with some adjustable tricks in the engine to align it with the palette.

Just imagining the fastest way for software engine to get some color, if it's not too horrible-looking. A little horrible is OK. Maybe will try it sometime.

[leileilol]

I think asm whipping would do the trick better than figuring out unorthodox new unproven ways of lighting. Colored lighting fully in C is too slow even for Pentium III. Having the ASM for drawspans does help a lot though to get it working okay on Pentium II but it can go potentially much faster with ASM on the 8RGB surface block.

If it's for Flash, then forget it. If it's for Dreamcast... hope you know SH4.

[dreadlorde]

My Core i7 should be able to handle software coloured lighting. Not everyone has the misfortune to be using pIII's.

[qbism]

An outline of how this would be implemented:
1. Load the lit file and BestColor each RGB entry to a palette index.

2. Generate avgColor[256][256] and addColor[256][256] lookup tables.

3. Umm, this is the hard part, and I'm oversimplifying... everywhere that light is added together, light += morelight becomes addColor[light][morelight]. Everywhere light is added to texture becomes avgColor. Or something like that.

4. The core of R_DrawSurfaceBlock8_mip0 loop becomes

Code: Select all

          byte *lightpal, *pixpal;
         for (b=15; b>=0; b--)
         {
            pix = psource[b];
            pixpal = host_basepal + pix*3; //qbism pal-lit
            lightpal = host_basepal + light*3;
            prowdest[b] = ((unsigned char *)vid.colormap)[avgColor[*pixpal][*lightpal]];  //or addColor?
            light += lightstep;
         }


Similar for other mip loops. "light" is not really a light value anymore, it's an indexed light color.

I'm still fantasizing for now, several critical flaws could emerge. It could wind up being slower than traditional RGB color implementations due to too many look-ups and conversions. The color error and/or reduced smoothing could be so harsh as to be unviewable.

Geared toward Flash, PocketPC, or similar low-power platforms where CPU may be unknown or assembly is a pain. In the big picture I don't know why I'm bothering with this... maybe just like thinking about palettes. These kinds of experiments are a good way to learn and generate other (workable) ideas.