32/24Bit Color Depth!

Tormentor667 · Post by **Tormentor667** » Sat Mar 19, 2005 4:47 pm

Every once in a while when working on a doom map I get to some frontiers concerning lights and stuff, especially fading, colored lighting and things like that... TNT4 would look so much better with 24/32Bit colors and I could add so many more light effects and interesting stuff, if I wouldn't be forged to work with just 8Bit

(

Siggi · Post by **Siggi** » Sat Mar 19, 2005 5:14 pm

I've been thinking about this.
If Zdoom were to be given 32bit colour - instead of making all the textures 32bit keep them all 8bit, but each with their own unique pallete. Then you would be able to have multiple palletes for a single object (mosnter or item or something) for when you want to simply change the colours around instead of having to create a whole new set of textures.

There is also the added benefit of having improved fog and sector coloured lighting.

Medricel · Post by **Medricel** » Sat Mar 19, 2005 5:58 pm

Of course, real 24/32 bit color is much quicker for a processor to do

Post by **Chris** » Sat Mar 19, 2005 7:48 pm

Not compared to 8-bit. 24-bit is evil and slow and should be made to un-exist. Though with proper MMX optimizations, 32-bit can be faster than 15/16-bit.

BouncyTEM · Post by **BouncyTEM** » Sat Mar 19, 2005 9:26 pm

this is a MUST HAVE!
/me becomes one of those hologram praying guys in Strife but wanting 32-bit color for Zdoom

QBasicer · Post by **QBasicer** » Sat Mar 19, 2005 9:55 pm

Psycho Siggi wrote:I've been thinking about this.
If Zdoom were to be given 32bit colour - instead of making all the textures 32bit keep them all 8bit, but each with their own unique pallete.

I think this is a bad idea, because then the engine has to match colours for everything, keeping it very messy and slow(er).

So it's doing 8bit-32bit-screen

Basically, if the engine sees (0,0,0) (RGB), then it looks at spot 0 on the pallete. If it sees (127,127,127), it looks at spot 127 on the pallete, and has to look at every pixel and colour each pixel. Unless this was done at startup, it would very extremely slow. (I guess ASM could speed it up though).

Unless there's a trick I don't know about.

wildweasel · Post by **wildweasel** » Sat Mar 19, 2005 9:56 pm

Chris wrote:Though with proper MMX optimizations, 32-bit can be faster than 15/16-bit.

While this may potentially make porting to Mac OS a little harder, I think it's worth the pain, because I'm sick of seeing a perfectly good graphic look like crap because of an 8-bit color ramp or shoddy translucency table.

QBasicer · Post by **QBasicer** » Sat Mar 19, 2005 9:57 pm

Mac OS doesn't support 32 bit?

wildweasel · Post by **wildweasel** » Sat Mar 19, 2005 9:58 pm

Mac OS doesn't support MMX. (Or rather, PPC processors don't have MMX.)

QBasicer · Post by **QBasicer** » Sat Mar 19, 2005 9:59 pm

The Mac might have other optimizations.

PS: I'm going to say this and duck, what about a move into OpenGL instead of a software based renderer?

Post by **Xaser** » Sat Mar 19, 2005 10:03 pm

Nah, not in stock Zdoom. I do agree that ZdoomGL needs to upgrade itself to newer Zdoom versions... assuming it hasn't already.

Csonicgo · Post by **Csonicgo** » Sat Mar 19, 2005 10:06 pm

are you kidding mÉ... ?

QBasicer · Post by **QBasicer** » Sat Mar 19, 2005 10:07 pm

OpenGL has a lot of features, but if everybody uses the Stock ZDoom, maps might not look good...

For example, does ZDoomGL support 32bit textures? If it doesn't it could be easy, but that woul dmean only some wads would work in GL.

Unless there was somethign to tell ZDoomGL what textures to use (32bit ones)

QBasicer · Post by **QBasicer** » Sat Mar 19, 2005 10:08 pm

Csonicgo wrote:are you kidding mÉ... ?

No.

Post by **Chris** » Sat Mar 19, 2005 10:21 pm

It would be nice if the renderer was moved into a completely seperate DLL/so, that way ZDoomGL could just be a DLL/so that ZDoom would see and allow you to pick.