DRD Team

It seems like GZDoom does not support true-color for player sprites while other true-color sprites works. Is that true?

GZDoom supports true color for all sprites.

What do you say about that?





It looks like something is wrong, does it?

Was it imported as a high color PNG? Remember that some wad editors (XWE) will convert PNGs to the classic paletted doom format unless you tell it not to (Load (Raw Data))

Also, check your player color

InsanityBringer wrote:Was it imported as a high color PNG? Remember that some wad editors (XWE) will convert PNGs to the classic paletted doom format unless you tell it not to (Load (Raw Data))

In SLumpEd it looks correct

InsanityBringer wrote:Also, check your player color

How should I set the player color to make it untouched?

milasudril wrote:

InsanityBringer wrote:Also, check your player color

How should I set the player color to make it untouched?

Define a new player class (see [wiki]Classes:PlayerPawn[/wiki] at the zdoom wiki), and don't set Player.ColorRange to anything. If you want to inherit from the DoomPlayer class, you'll need to set Player.ColorRange to something like 0 0

InsanityBringer wrote:

milasudril wrote:

InsanityBringer wrote:Also, check your player color

How should I set the player color to make it untouched?

Define a new player class (see [wiki]Classes:PlayerPawn[/wiki] at the zdoom wiki), and don't set Player.ColorRange to anything. If you want to inherit from the DoomPlayer class, you'll need to set Player.ColorRange to something like 0 0

It looks still wrong. This one gives a more clear example:

There does seem to be something odd going on. Regardless of whether I inherit from DoomPlayer and employ the "Player.ColorRange 0, 0" trick or whether I defined a class that inherits from "PlayerPawn" and leave out the color range completely, my player sprite seems to get forced into 256 colours (and it looks like the 256 colours are indeed the Doom palette [edit] Confirmed, in other games it uses colours from their palette[/edit]).

Using this as a player sprite:



I get this when I start a game:



but in a game with chasecam on it looks like this:



and even in the menu once a game has started it looks like this:



The question is, is this a bug or is it by design?

Things seems to become right after a call to MorphActor.
After that, the sprite looks good (if the player not already is of class xxx. This looks like a bug.

Player sprites have a translation forced upon them. Unless ZDoom finally implements the often suggested 'do not translate' feature I can't do much about it. It's simply not possible to decide whether the translation is bogus or not.

Graf Zahl wrote:Player sprites have a translation forced upon them. Unless ZDoom finally implements the often suggested 'do not translate' feature I can't do much about it. It's simply not possible to decide whether the translation is bogus or not.

What about according to the ZDoom wiki, this implies no translation. What about the MorphActor hack?

I do not know how the translation works, but one way to do it in indexed mode is to replace some predefined (I guess the color index to replace is selected by the ColorRange property) colors in the palette. When the sprite is true-color, this solution does not work. Because it is known that the PNG is true-color you can decide to not translate using this algorithm.

For a true-color sprite it is a better idea to replace all pixel that have a color in the HSL or HSV space within the neighbourhood of a predefined color ignoring L/V. That is, replace all colors that has a similar hue and saturation as the color to replace and set them to the hue and saturation of the replacing color. The lightness/value component of the original color is then multiplied by the lightness/value component of the replacing color. This algorithm will work for both indexed and true-colored sprites but requires probably a new PlayerPawn property.

Even if there's no color range the translation is still there