32/24Bit Color Depth!

Post by **Graf Zahl** » Tue Mar 22, 2005 3:54 am

Chris wrote: 32-bit color has 24-bits of color and 8-bits of junk,

On most cards it is used as a destination alpha channel, although I haven't seen any good use for it so far.

QBasicer · Post by **QBasicer** » Tue Mar 22, 2005 5:15 am

I was looking at it from a purly applicational level.

Tormentor667 · Post by **Tormentor667** » Fri Mar 25, 2005 7:51 am

Tormentor667 wrote:Well, when I started this topic, I had something else in mind: Keep the DoomPalette for textures, things and everything else, but add the possibility of 32Bit ingame, so you can apply different colors for sector_setcolor, sector_setfade and other stuff like that. Even the light levels itself would look by far better from 0 - 192 if we hade 32Bit! Think about cyan or purple faded rooms, bright blue lights in rooms or things like that This would enhance doom, it really would and there wouldn't be a need to change something about the doompalette itself right now!

Chilvence · Post by **Chilvence** » Fri Mar 25, 2005 7:57 am

Ok, what would be the point of working on an entirely new 32 bit colour renderer, and then restricting the palette it can use afterward? If you want to stick with the Doom palette, no one is going to stop you, so why would you want to limit it in a needless way? You of all people should realise that you can easily stick to the Doom colour scheme yet use a smoother range of shading if you don't restrict the palette.

Post by **Graf Zahl** » Fri Mar 25, 2005 8:12 am

Especially considering that PNGs with different palettes can already be loaded although they get remapped after loading. But with a true color renderer there is no need to remap palettes because in the end it's all the same no matter what palette you use to render it.

So making the renderer 32 bit but forcing the textures to Doom's shitty palette seems rather counterproductive to me.

QBasicer · Post by **QBasicer** » Fri Mar 25, 2005 8:20 am

I think it would also slow it down, at one point or the other (like if they were cached with the pallete, that's a lot of colours to translate.)

Post by **Graf Zahl** » Fri Mar 25, 2005 11:29 am

The only differenct would be that instead of translating 8 bit -> 8 bit it'd be 8 bit -> 32 bit. Yes, the palette tables are larger but for the rendering process itself that'd be it. Of course you'd need to transfer 4 times as much data to the graphics card in the end so yes, it would be slower but 800x600 in 32 bit looks definitely better than 1024x768 in 8 bit.

QBasicer · Post by **QBasicer** » Fri Mar 25, 2005 11:38 am

I think keeping an 8 bit doom pallete is a silly idea anyways.

What if you wanted a texture of a picture of somebody or something?

How many games do you see that are modern are 8bit?

Ultraviolet · Post by **Ultraviolet** » Fri Mar 25, 2005 5:45 pm

IMHO, this feature request is like... Doom -- the way it was meant to be!

Post by **Graf Zahl** » Fri Mar 25, 2005 7:05 pm

What I'd like to have is a robust hardware accelerated renderer. It doesn't need to have dynamic lighting and other modern crap that just doesn't fit the game. Maybe Polymost will bring it...

Penguinx · Post by **Penguinx** » Fri Jul 15, 2005 5:19 pm

I, unfortunately, thought zDoom DID support a 32 bit palette and created a bunch of sprites and textures in vein. I whole-heartedly support the addition of this feature. In fact, I desperately need it.

I refused to use jDoom for high-res sprites and textures and all the levels and custom monsters I've worked on for this TC use zDoom as their base; Gah!

Post by **Graf Zahl** » Fri Jul 15, 2005 6:01 pm

Then you are desperately out of luck. Don't expect 32bit color any time soon.

anonone · Post by **anonone** » Fri Jul 15, 2005 7:22 pm

If anybody's played the Win32 port of Duke3D, polymost is delicious. That's the only way I can describe it. I'd be ecstatic if Randy managed to get that working in ZDoom.

Penguinx · Post by **Penguinx** » Fri Jul 15, 2005 10:44 pm

Graf, I know. I can hope, however.

Siggi · Post by **Siggi** » Sat Jul 16, 2005 2:25 am

Graf Zahl wrote:What I'd like to have is a robust hardware accelerated renderer. It doesn't need to have dynamic lighting and other modern crap that just doesn't fit the game. Maybe Polymost will bring it...

Seeing as I've been an advocate of "ZDoom in 32bit", I think it is necesarry to point out how important this remark is.

I personally have a problem with a port when it gets OpenGL and DirectX because it is usually followed by that port being filled with un-Doomlike, pointless graphic features (lense flares, dynamic lighting, 3D models, etc... ).

Personally, I'm perfectly fine with ZDoom's renderer the way it is - if it means that these silly features will be left out. Although, I'm fully aware that my point of view on this matter is unpopular. Somehow most Doomers are atracted to the deceiving, eye-candy of JDoom and allot have suggest things allong the lines of a ZDoom-JDoom combo being the best port ever.

But it is my belief that the lack of a 3D renderer in ZDoom is the reason for its success. I can quite confidently say that ZDoom is the most popular port. This popularity is due to it huge list of usefull editing features and its optamised performance. I don't believe that these enhancements would have been at the level they are now if Randy had chosen to program a new 3D renderer for ZDoom when the opertunity first came to do so.

I realise that for 32bit graphics to be implemented in ZDoom it is most likely that there will have to be an upgrade of the renderer as to keep the performance levels where they are. What Graf has said here is IMO the best solution: a robust hardware accelerated renderer that doesn't have all the modern crap implemented. Lets keep ZDoom's focus where its allways been, and where it should remain,,, on all those usefull editing features!