Dropping the palette: rendering 256-colors directly from tex

Discuss programming topics for the various GPL'd game engine sources.
JasonX
Posts: 422
Joined: Tue Apr 21, 2009 2:08 pm

Dropping the palette: rendering 256-colors directly from tex

Post by 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
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Re: Dropping the palette: rendering 256-colors directly from

Post by 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)
i should not be here
JasonX
Posts: 422
Joined: Tue Apr 21, 2009 2:08 pm

Re: Dropping the palette: rendering 256-colors directly from

Post by JasonX »

24-bit in software? Isn't that going to be slow?
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Dropping the palette: rendering 256-colors directly from

Post by 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
Posts: 422
Joined: Tue Apr 21, 2009 2:08 pm

Re: Dropping the palette: rendering 256-colors directly from

Post by 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
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Re: Dropping the palette: rendering 256-colors directly from

Post by leileilol »

JasonX wrote: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.
i should not be here
JasonX
Posts: 422
Joined: Tue Apr 21, 2009 2:08 pm

Re: Dropping the palette: rendering 256-colors directly from

Post by 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
Posts: 422
Joined: Tue Apr 21, 2009 2:08 pm

Re: Dropping the palette: rendering 256-colors directly from

Post by JasonX »

Spike wrote: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
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Dropping the palette: rendering 256-colors directly from

Post by 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
Posts: 1065
Joined: Sat Nov 20, 2004 9:00 pm
Contact:

Re: Dropping the palette: rendering 256-colors directly from

Post by Spirit »

Too lazy too look up where but Baker has added HL texture support to some of his engine improvement projects.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Dropping the palette: rendering 256-colors directly from

Post by Baker »

Spirit wrote: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.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Dropping the palette: rendering 256-colors directly from

Post by 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
Posts: 422
Joined: Tue Apr 21, 2009 2:08 pm

Re: Dropping the palette: rendering 256-colors directly from

Post by JasonX »

Baker wrote:
Spirit wrote: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. :D
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Dropping the palette: rendering 256-colors directly from

Post by 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.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
JasonX
Posts: 422
Joined: Tue Apr 21, 2009 2:08 pm

Re: Dropping the palette: rendering 256-colors directly from

Post by 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);
}
Post Reply