[r643 and beyond]Graphic discoloration

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49252
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: [r643 and beyond]Graphic discoloration

Post by Graf Zahl »

No, the black boxes come from color index 0 being mapped to palette entry 1.
User avatar
randi
Site Admin
Posts: 7749
Joined: Wed Jul 09, 2003 10:30 pm
Contact:

Re: [r643 and beyond]Graphic discoloration

Post by randi »

Do you think it would help you experiment if I made an attempt to explain what these cvars do? Here goes.

Inside the game, the palette is stored in one long row, rather than 16 as seen here. The pal cvar controls where it looks up color 0. The default value of 0.5 should place it directly in the middle of the first palette entry. A value of -1.5 would make it look directly in the center of a nonexistant entry before the first one, and a value of +1.5 should make it look directly in the center of the second palette entry. So by increasing this, you throw away entries at the start of the palette and shift everything left. By decreasing this, you throw away entries at the end of the palette and shift everything right.

To determine where to look up color 255, pc is added to pal. This means that the default value of 255 will have it looking at location 255.5, which should be directly in the center of the last palette entry (number 255). Each color in between should be evenly spaced between these. Unfortunately, that's not the way it's working on your card, so I'd like to find some combination of the two values that will map each color to a unique palette entry.

But explaining this has given me the idea to try doing the mapping with an interpolation instruction instead of a multiply-and-add instruction. Maybe that will work better. Edit: Nevermind. Shader Model 1.4, which is what the Radeon 9000 supports, doesn't have a lerp instruction, so it fakes it with a multiply and add anyway.

(I am so glad that later ATI cards do not have this problem.)
User avatar
randi
Site Admin
Posts: 7749
Joined: Wed Jul 09, 2003 10:30 pm
Contact:

Re: [r643 and beyond]Graphic discoloration

Post by randi »

After acquiring my own Radeon 9000 (and spending way too much time uninstalling and reinstalling drivers), I have verified that it does indeed seem impossible to program this card to not skip a palette entry. I've fixed it, working under the assumption that all R200-derived cards suffer this problem. I also fixed a few other issues that I found with this card.
User avatar
Anakin S.
Posts: 1067
Joined: Fri Nov 28, 2003 9:39 pm
Location: A long time ago in a galaxy far, far away...

Re: [r643 and beyond]Graphic discoloration

Post by Anakin S. »

Thank you very much.
Post Reply

Return to “Closed Bugs [GZDoom]”