Dropping the palette: rendering 256-colors directly from tex

[JasonX]

[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 )

[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]

[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]

[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]

[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]

[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]