- Load textures
- Load palette and colormap
- Map the texture color info into the appropriate palette
- Put into the pipeline with D_DrawSpans8
Dropping the palette: rendering 256-colors directly from tex
Dropping the palette: rendering 256-colors directly from tex
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:
Re: Dropping the palette: rendering 256-colors directly from
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)
(Which is possible and clever trickery can make it work in 256 colors)
i should not be here
Re: Dropping the palette: rendering 256-colors directly from
24-bit in software? Isn't that going to be slow?
Re: Dropping the palette: rendering 256-colors directly from
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.
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.
Re: Dropping the palette: rendering 256-colors directly from
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.
Re: Dropping the palette: rendering 256-colors directly from
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)JasonX wrote:24-bit in software? Isn't that going to be slow?
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
Re: Dropping the palette: rendering 256-colors directly from
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
Re: Dropping the palette: rendering 256-colors directly from
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 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.
Re: Dropping the palette: rendering 256-colors directly from
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.
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.
Re: Dropping the palette: rendering 256-colors directly from
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
Re: Dropping the palette: rendering 256-colors directly from
He's wanting to do this with WinQuake, not the GLQuake. Big difference.Spirit wrote:Too lazy too look up where but Baker has added HL texture support to some of his engine improvement projects.
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? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: Dropping the palette: rendering 256-colors directly from
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.
everything becomes easier when you're willing to strip out everything.
Re: Dropping the palette: rendering 256-colors directly from
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 wrote:He's wanting to do this with WinQuake, not the GLQuake. Big difference.Spirit wrote:Too lazy too look up where but Baker has added HL texture support to some of his engine improvement projects.
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.
Re: Dropping the palette: rendering 256-colors directly from
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.
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? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: Dropping the palette: rendering 256-colors directly from
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);
}