Dropping the palette: rendering 256-colors directly from tex

[JasonX]

I've been trying to modify the existing Q1 software renderer to allow rendering 256 colors, directly from the texture palette, like HL1 does. I've read some material by ID where Carmack says that would be possible by using SIMD extensions and make some proper calculations. However, the existing code is quite cryptic and i'm having a hard time understanding the whole palette usage. Right now, the game appears to:

• Load textures
• Load palette and colormap
• Map the texture color info into the appropriate palette
• Put into the pipeline with D_DrawSpans8

Am i correct? Has anyone adventured into this kind of modification?

[leileilol]

Considering the upgrades necessary to make the surfacecache suitable for this (DO NOT FORGET THE MIPBLOCK FUNCTIONS which comes before drawspans) you'd better off be just directly loading all textures as 24-bit at this point.


(Which is possible and clever trickery can make it work in 256 colors)

[JasonX]

24-bit in software? Isn't that going to be slow?

[Spike]

about as slow as looking up the texel's rgb value, scaling by lightmap, then scanning through the palette to find the palette index that best matches that colour...
iirc, halflife's software renderer was 16bit, meaning it could skip that last step, thus faster.
you could implement that last step using a lookup table, but it will destroy cpu cache.

[JasonX]

I have no idea how to implement 24-bit in the current software renderer. I mean: where i'll get the color information from? In the case of HL1, the loaded texture contains the color information.

[leileilol]

24-bit in software? Isn't that going to be slow?

It'll only be slower for buffer transfer on slower machines and their slow video cards, and the fact there's no Abrash assembly code for 24-bit color (though there is leftover 16bpp assembly code that I'm not sure if it even works since that was implemented around 1995 when Quake was revealed with those big high-color TIF pictures with the Doom numbers)

FYI UnrealEngine's softdrv was purely 24-bit and ran good enough for those who are stuck with it on P2 systems with crappy video cards.

[JasonX]

UT's software renderer was very nice. Do you guys know if there's any technical info about it somewhere? The only one i could find was this: http://www.flipcode.com/archives/Textur ... real.shtml

[JasonX]

about as slow as looking up the texel's rgb value, scaling by lightmap, then scanning through the palette to find the palette index that best matches that colour...
iirc, halflife's software renderer was 16bit, meaning it could skip that last step, thus faster.
you could implement that last step using a lookup table, but it will destroy cpu cache.

I was taking a look at FTE's software renderer and... well, it's completely different from Q1's! Have you written it from scratch?

[Spike]

FTE has no official software renderer.
if you look in the svn history, you should be able to find one, most revisions will be buggy and unusable in some way of course, which is why it got stripped.

[Spirit]

Too lazy too look up where but Baker has added HL texture support to some of his engine improvement projects.

[Baker]

Too lazy too look up where but Baker has added HL texture support to some of his engine improvement projects.

He's wanting to do this with WinQuake, not the GLQuake. Big difference.

WinQuake you get one 256 color palette. Period. All the 25+ software renderer source code files expect one byte (an 8-bit number from 0-255) for each pixel.

[Spike]

fte's old software renderer had 24bit colour depth. for lighting, anyway. for wall textures it didn't support truecolour or even custom palettes. *someone* was too lazy to write such stuff into the loader, let alone using multiple input formats etc. it still had 8bit rendering too, so that sort of thing would have been a pain.

everything becomes easier when you're willing to strip out everything.

[JasonX]

Too lazy too look up where but Baker has added HL texture support to some of his engine improvement projects.

He's wanting to do this with WinQuake, not the GLQuake. Big difference.

WinQuake you get one 256 color palette. Period. All the 25+ software renderer source code files expect one byte (an 8-bit number from 0-255) for each pixel.

Exactly. But if i'm loading the colors from the texture palette, instead of the global palette, i don't have to change the 8bit data. I'm just trying to find how to do this.

[Baker]

If you want to do 257 colors in a 1-byte pixel that has a range 0-255, you are out of luck. And that's the screen buffer (width * height * 1) in WinQuake.

You would need to rewrite the 25+ source files to accept 2-byte colors (65536 and do R5G6B5 color) or to accept 3-byte colors (R8G8B8) for screen buffer. FTE 3343 shows the way. Your video buffer will be (width * height * 2 or 3).

The original WinQuake source code does have r_pixelbytes variable spread throughout the source code where r_pixelbytes = 1 is WinQuake and r_pixelbytes = 2 would be 16-bit color, and maybe with enough persistance and trial and error you might be able to expend a whole ton of effort and activate that.

[JasonX]

I can just change all bytes to unsigned int. Then, inside Mod_LoadTextures:

Code: Select all

unsigned int *pDest = (unsigned int *)(tx + 1);
byte *pSrc = (byte *)(mt + 1);
byte *palette = pSrc + ((mt->width * mt->height * 85) >> 6) + 2;
int index;

for (index = 0; index < pixels; index++) {
    int r, g, b;
    r = palette[pSrc[index] * 3];
    g = palette[pSrc[index] * 3 + 1];
    b = palette[pSrc[index] * 3 + 2];
    pDest[index] = b | (g << 8) | (r << 16);
}