Colour Map Support for GZDoom
Moderator: GZDoom Developers
- Pixel Eater
-
- Posts: 667
- Joined: Wed Aug 02, 2017 12:31 am
- Location: In between the Moon and you, between the buried and me.
Colour Map Support for GZDoom
Would it be possible to have a future release of GZDoom read from a longer lookup table with higher colour depth?:
DooM Colour Map Expanded 8x
This widened version shows how the index colours don't blend across columns:
It's quite easy to make this from an existing colour map (~5mins) and would re-enable custom effects that are no longer supported.
Plus- colours can fade like Doom originally did but in a much smoother way
DooM Colour Map Expanded 8x
This widened version shows how the index colours don't blend across columns:
It's quite easy to make this from an existing colour map (~5mins) and would re-enable custom effects that are no longer supported.
Plus- colours can fade like Doom originally did but in a much smoother way
Last edited by Pixel Eater on Mon Aug 13, 2018 4:11 pm, edited 1 time in total.
- phantombeta
- Posts: 2084
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: Colour Map Support for GZDoom
This probably won't happen, I think. COLORMAP is only used by the paletted software renderer AFAIK, which would mean it's useless for the rest of the engine.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Colour Map Support for GZDoom
The colormap is a palette to palette mapping. This cannot possibly work with a hardware renderer and even if it could, it'd nullify all advantages of true color rendering.
- Pixel Eater
-
- Posts: 667
- Joined: Wed Aug 02, 2017 12:31 am
- Location: In between the Moon and you, between the buried and me.
Re: Colour Map Support for GZDoom
Phantombeta, I was suggesting it be implemented so that either engine could. Are you implying that the roadblock could be OpenGL itself?
I wonder if software mode's new truecolour ability could be adapted for this purpose.
Graf, thanks for the clarification on whether hardware can support this.
My thoughts were that this would be true colour (removes banding), eventually and still provide for interesting customisations. Are there other advantages I'm missing, render speed? Do you think this can be accomplished with the software engine?
In case I'm not explaining myself well here's a .gif showing the banding being removed:
(Click for animation)
I wonder if software mode's new truecolour ability could be adapted for this purpose.
Graf, thanks for the clarification on whether hardware can support this.
My thoughts were that this would be true colour (removes banding), eventually and still provide for interesting customisations. Are there other advantages I'm missing, render speed? Do you think this can be accomplished with the software engine?
In case I'm not explaining myself well here's a .gif showing the banding being removed:
(Click for animation)
Last edited by Pixel Eater on Mon Aug 13, 2018 4:13 pm, edited 1 time in total.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Colour Map Support for GZDoom
Like I said, a colormap maps from palette index to palette index. OpenGL does not use palettes at all so it simply cannot do such a thing.
Re: Colour Map Support for GZDoom
The roadblock isn't OpenGL, the roadblock is that ZDoom supports truecolor resources. How does your colormap work with colors outside the palette? It doesn't. So either you force everything into the palette (and that's going to look ugly very quick) or you force everything to truecolor. The latter doesn't degrade image quality but means colormaps aren't used anymore.Pixel Eater wrote:Are you implying that the roadblock could be OpenGL itself?
Theoretically, to support color maps in truecolor mode, you'd have to iterate through each pixel, check if it's in the palette (that means performing 256 color comparisons), if so branch to color lookup in the colormap, if not branch to normal algorithm. That can't be good for performances. Alternatively, have two different rendering pipelines, one for paletted assets and another for truecolor ones. Talk about a headache.
You're just smoothing the banding, not removing it. A long while ago I posted what the colormaps would look like in truecolor (if you don't force the computed colors back in the palette). Here's the "truecolormap", with below the actual colormap for comparison:Pixel Eater wrote:My thoughts were that this would be true colour (removes banding), eventually and still provide for interesting customisations. Are there other advantages I'm missing, render speed? Do you think this can be accomplished with the software engine?
Re: Colour Map Support for GZDoom
Actually, you can do that in OpenGL - the shader in the hardpoly branch is doing that right now. It works by letting the shader operate with palette indices internally (colormaps placed in textures) and then outputs the RGB color for the final palette index at the end.Graf Zahl wrote:Like I said, a colormap maps from palette index to palette index. OpenGL does not use palettes at all so it simply cannot do such a thing.
What OpenGL cannot do is blend with palette indices. The good news is that neither can ZDoom - it cheats by converting it to RGB, then blends, and converts it back to a palette index (via the rgb555 and rgb666 tables). This is effectively the same as if the fragment shader returned the RGB color, OpenGL alphablends, and then a palette "tonemap" pass forces them back into valid palette colors.
All that said, I agree that this should be No'ed on the basis that we need solutions that allow palette and truecolor to use the same light gradients. We already have the problem with Square that it desaturates the colors in the colormap, which the GL and TC renderers cannot know about and therefore doesn't do. This feature would just invite such techniques to become more popular.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Colour Map Support for GZDoom
It also cannot do texture filtering with such a setup unless it is coded inside the shader.dpJudas wrote: What OpenGL cannot do is blend with palette indices.
Re: Colour Map Support for GZDoom
True, but texture filtering would break on the CPU as well for a palette renderer as how do you mix between four palette indices? No matter what you do, it would have to convert it to true color and then back again via some rgb555 style table.Graf Zahl wrote:It also cannot do texture filtering with such a setup unless it is coded inside the shader.
- Pixel Eater
-
- Posts: 667
- Joined: Wed Aug 02, 2017 12:31 am
- Location: In between the Moon and you, between the buried and me.
Re: Colour Map Support for GZDoom
True, It wasn't intended to. I see what you mean, it wouldn't support 24bit .png files. That would be a bummerHow does your colormap work with colors outside the palette? It doesn't.
Your picture demonstrates what I was hoping to rectify, the simplified colour map that the hardware renderer generates. I like it's smoothness but it loses the richness of the software version.
I've overlaid mine to show the extra complexity that could be gained:
(Click to animate)
Although it was only a proof-of-concept, nothing definitive...