Hi-color images in source ports?

[ludicrous_peridot]

Have a rather generic question on using pics with pixels or color that is not found in the PLAYPAL lump. As I understand Doom lighting effects (such as diminishing light) have historically been working using pallete tricks, that retained the colorspace of 256 distinct colors. 

 

Now on modern ports when a texture is defined e.g. with a PNG that has colors outside of that space, how is this handled? Is the color coerced into one of the pallete colors, or is there some kind of interpolation applied? 

 

I think this will depend on port and renderer used, so appreciate all the answers. Thanks!

[Gez]

You have basically only two options here:

1. Force the image into the palette and apply the COLORMAP as usual
2. Ignore the COLORMAP and change brightness algorithmically

Usually, software renderers will do the former while hardware renderers will do the latter.

[Dark Pulse]

On 1/14/2022 at 2:48 AM, ludicrous_peridot said:

Have a rather generic question on using pics with pixels or color that is not found in the PLAYPAL lump. As I understand Doom lighting effects (such as diminishing light) have historically been working using pallete tricks, that retained the colorspace of 256 distinct colors. 

 

Now on modern ports when a texture is defined e.g. with a PNG that has colors outside of that space, how is this handled? Is the color coerced into one of the pallete colors, or is there some kind of interpolation applied? 

 

I think this will depend on port and renderer used, so appreciate all the answers. Thanks!

If I'm interpreting this right, PNGs are applied "as-is" because the source port reads them as their own separate thing - it knows it's not a Doom format texture, and so reads it differently. A PNG has all of its color information embedded within the file itself (including color depth), so as far as the source port is concerned, it just needs to be told "read this PNG and apply it."

 

I'm at least presuming this is the case since I'm working on a game mod that uses 4-bit PNGs for wall textures and 1-bit PNGs for flats (the source game just used solid colors for those), and while at one point I'd had all of the source game's color values in my PLAYPAL, I realized there was no real way to tell it to swap the colors (otherwise I would've only needed one copy of the textures, instead of twelve or so in different palettes), so I removed the wall colors from my PLAYPAL. However, me being able to reduce them to 4-bit PNGs shaved off a lot of space (about 10 MB), and the textures display perfectly fine, so it's got to be reading the embedded color info and using those.

 

Mind you, this is with GZDoom, but I don't see why this wouldn't apply to any PNG-friendly source port.

Edited January 16, 2022 by Dark Pulse

[ludicrous_peridot]

My finding with GZDoom is the same: it would show the PNGs as I see them in graphics editor, regardless of the PLAYPAL contents. Eternity on the other hand would show exactly what I see when in Slade I open the graphics conversion dialog, so I suspect it's coded to convert PNGs into patches upon loading them (and I was unable to get PNGs working for flats in Eternity for some reason). Haven't tried EDGE nor GZDoom software mode at all and have seen on the forums that ZDoom does the conversion as well.

 

For my mod, since I wanted to preserve Doom sprites look, instead of crafting a palette that would match my non-PLAYPAL-fitting textures (also converted from a 4bpp source, by the way, but with 15bit effective colorspace) I made 2 sets of them (original PNGs and PLAYPAL-converted patches and flats) and 2 sets of maps, using ZMAPINFO to instruct GZDoom to load the maps with "hi fidelity" assets in the same wad.

[Dark Pulse]

1 hour ago, ludicrous_peridot said:

For my mod, since I wanted to preserve Doom sprites look, instead of crafting a palette that would match my non-PLAYPAL-fitting textures (also converted from a 4bpp source, by the way, but with 15bit effective colorspace) I made 2 sets of them (original PNGs and PLAYPAL-converted patches and flats) and 2 sets of maps, using ZMAPINFO to instruct GZDoom to load the maps with "hi fidelity" assets in the same wad.

Yeah, that works totally fine if you're just adding/replacing graphics and such.

 

For me though, I actually need to have new actors and behaviors, and so I'm dabbling in the dark arts of DECORATE/ZScript.

 

I suppose someone could eventually convert it to EDF if they really wanted to, though.