InsideQC Forums

I am ready to admit that maybe this not a very smart (or even feasible) idea, but what if the engine just store the pallete with the texture and switch palletes during rendering ? You'd still have the main default pallete to render any stuff that don't have a custom one. Wasn't Quake 2 sw render like this ?

not feasable. the palette colours are provided by the graphics hardware (although nowadays more commonly by a bit of code copying it out to the actual framebuffer later...). meaning you can't have some pixels using one palette and others using a different one.
you still need to change *all* the code to throw true-colour values at the screen.

fte's software renderer was 32bit. 24bit colour depth, but 32bit. hurrah for padding. noone uses actual 24bit framebuffers due to alignment issues.

updating code to use a truecolour framebuffer can at least be done gradually. code that isn't updated yet will merely draw to the wrong part of the screen, its not a problem until you want to take promo screenshots.
even if your source texture remains 8bit, you will likely want to make sure that your surfacecache is truecolour too. then your rasterizing code can just copy ints instead of bytes to the screen.

frag.machine wrote:Wasn't Quake 2 sw render like this ?

Q2 maps have external 8-bit textures stored without palette information (.wal files). The palette and pre-calculated color blends are loaded from colormap.pcx. It's still just one palette for all textures.

frag.machine wrote:but what if the engine just store the pallete with the texture and switch palletes during rendering ?

Bad idea: You would need a generated loopup table for every unique texture palette each, regardless of pixel depth.


But anyway, going this over:

- You really really need a 15-bit, 16-bit or 24-bit surfacecache to store these textures
- You also need a new DrawSpans to draw colors from this properly
- You may also need to tear your video code for supporting this new bit depth directly, otherwise you'll have to dither it at the span level
- Also you would need to tear up the sky drawing code and water rendering code to support your rgb textures
- Another function you have to go to is the SurfaceMip functions in r_surf.c, which are responsible for blending the lightmap together with the texture, writing into this surfacecache for DrawSpans to use. That would need upgrades for either supporting the textures, and to have more bytes for the new high/true color DrawSpans (even regarding dithered spans). and this isn't even considering scratching the surface that is colored lighting, but that should be implemented anyway for the sake of color concurrency
- Unrelatedish, but it could be possible to have a 32-bit surfacecache and just use the extra bits to denote fullbright colors instead of alpha (for upconverting Quake textures and parsing _glow textures) - to make use out of the 'alignment' waste. Maybe for translucent textures the bits could be shifted a little to have both glow and alpha data.

This gif here shows:

Frame 1 - 8bpp DrawSpans, 8bpp surface cache, standard mono 8bpp lighting, 8bpp textures converted to game palette on load
Frame 2 - 8bpp DrawSpans, 8bpp surface cache, 18bpp lighting, 8bpp textures converted to game palette on load
Frame 3 - 8bpp DrawSpans w/ 2x2 dither, 15bpp surface cache, 15bpp lighting, 15bpp textures converted from textures' palette


I don't mean to plug my engine (the feature was never completed -it didn't do water/skies), but I have dablled in this idea, and so has Spike at one point. Earlier FTEQW revisions should still have the software renderer with 16/32bit modes with paletted WAD3 texture support (which I learned a lot from BTW FYI)

Going to 16-bit or 32-bpp probably loses:

1) Bonus flashes (green flash when picking up item)
2) Damage shift (red flash when being hurt)
3) Quad/Pent/Suit
4) Cshifts a mod may use
5) Loss of palette based gamma control (and possibility of contrast control)

Or so I would guess.

what? all that colorshifting stuff could be done directly at flip

gl-style hardware gamma is a possibility
running an extra pass through the screen before/while writing it to the hardware is possible, but 3 separate lookups per pixel can be expensive.
definitely possible, just less desirable.