Dropping the palette: rendering 256-colors directly from tex

[frag.machine]

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 ?

[Spike]

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.

[qbism]

[leileilol]

[Baker]

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.

[leileilol]

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

[Spike]

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.