jval
Member
Posts: 259
Registered: 0905 
Gez said:
Even colormap hacks?
The true color renderer ignores by default COLORMAPS #1 thru 32 and only uses COLORMAP #0. Then insdead of using COLORMAPS #1 thru #31 for brightness, it calculates the lightlevel in a more linear way (no ugly transactions for brightness changing in the zdepth axis) and instead of COLORMAP #32 it calculates the inverse color.
If 'forcecolormaps' console variable is set to true (default is false  Menu command: Options/Display/32 bit rendering/"Use 32 bit colormaps"), in some cases uses the colormaps, but mostly "hacks" the lightlevel to emulate the light transactions of the 8 bit renderer.
What it does so far is transforming a true color texture to match the changes that a custom colormap makes to a paletted patch.
The algorythm I used is the following:
For each custom colormap I create a 3 dimentional array <long LUT[X][X][X]> where X is a N power of 2 (N=4 or N=5 bits are OK to work with, i.e. X=16 or 32).
Each dimention of the LUT array represents a value of RGB color, eg if LUT[10][8][7] stores the new color for RGB(10<<(8N),8<<(8N),7<<(8N)) after applying the colormap transformation.
The number of significant bits does not affect rendering performance, only memory usage and loading time (the timeconsuming calculations of the "transformation" occur only the first time the colormaps are loaded)
When a custom colormap is in use, the renderer transforms each pixel of an external texture using the above LUT.
For example, if we have a 4 bits precision LUT and the color of current pixel is RGB(BINARY{00111101},BINARY{01101011},BINARY{01001010}) the transformed color will be LUT[BINARY{0011}[BINARY{0110}][BINARY{0100}] without the time consuming calculations of colormap transformation.
After that we can decide if we will use the new color unchanged (so far that's what I do), or apply any precision corrections (eg average with next LUT items), that depends on the huppy medium between performance/quality. Even if we use precision corrections we avoid the timeconsuming calculations of colormap remap in 32 bit texture. A LUT of 5 BITS precision gives very good results for the naked eye without using any corrections. In fact many colormaps are using just a single color, for example BLUMAP uses only blue color values, so even with a 3 BITS precision LUT we can achieve 512 different color remap table, more than the 256 distinct blue tints that RGB color representation can hold.
This technique can also be applied to COLORMAPS #1 thru #32 if they don't "obey" the default "laws" of DOOM engine, if someone can give me a download link of such mod will be greatly appreciated.
