ZDoom

This shader attempts to smooth the banding that is found even in OpenGL, something which proves 8 bits per channel is too low even for GZDoom.

This shader is always on and has no configuration options. Its effect is very subtle and barely noticeable (it's more noticeable when it's not loaded, actually), so I didn't really see the need to include an on/off switch.

Basically, it is designed strictly for 24-bit displays, which have trouble at the lower colour bands showing gradients smoothly.

Both of these screenshots are doctored in such a way to attempt to show off the effect of the shader. Under normal conditions you will not see it.

Before:


After:


Before you ask, YES you are allowed to use this in your mod! (Or even your commercial game, without royalty!) There is a license that's basically, there's no warranty, and give me credit.

This looks pretty awesome Rachael! I think I'm gonna try integrating it to DarkDoomZ, since that's basically all about the lower color bands.

Thank you, and that sounds good.

24 Bit as in 32 Bit = 24 Bit color + 8 Bit Alpha channel?

Yes. No matter what your desktop colour resolution is set to, the final result is downsampled when your monitor receives it.

It's supposed to be 24-bit, but from what I understand some monitors are often actually 18-bit and either they, or the GPU, do internal dithering of sorts to make up the difference.

Too bad that 30 bit hasn't become standard yet, that'd make such things pretty much unnecessary.
In a way it reminds me at how old graphics hardware tried to 'improve' the look of 16 bit output with dithering, of course with such a low bit depth to start it was a mostly hopeless undertaking.

This one doesn't have much of an effect in bright scenes but testing with some really dark map it nearly completely removes the banding. I'm all in favor of making this an official postprocessing effect.

I've found even when developing this shader, that 30-bit presents a bit of banding with GZDoom. This shader simulates 36-bit which is an extremely high colour resolution, that seems to be enough to eliminate the banding, mostly.

So even when 10bpc displays start to become common, I expect I'll have to update this shader again for the new colour resolution, dividing the first line by 2048 instead of 512. But that's still much better than what we have, today.

Although, I start to wonder at what point the floating point precision errors will start kicking in.

Rachael wrote:I start to wonder at what point the floating point precision errors will start kicking in.

A lot later. I think 16 bpc should be fine unless some really complex stuff gets done.

This one doesn't have much of an effect in bright scenes but testing with some really dark map it nearly completely removes the banding. I'm all in favor of making this an official postprocessing effect.

This is licensed so you are free to grab it and go, you can include it in any of your projects if you want to.

I am not really sure how to implement it into GZDoom, myself, but I am looking at it.

It shouldn't be too hard. The main question is, where in the chain is the most appropriate place.

Ideally, the very last place where the colour channels are still floats, before they are transmitted to the window for presentation to the user. If it can be done after the resolution scaling, that would be even better.

Also, the definition at the top of the file (right under the BSD notice) can be changed as follows: This allows you to put 8 or 10 in as colourdepth - something that will allow you to set the stipple to tune to a 8bpc display or a 10bpc display. The "halfcolour" variable is the most important switch to the entire shader program that tells it how to stipple the display.

Rachael wrote:If it can be done after the resolution scaling, that would be even better.

Agreed. But that's after the application of the 2D HUD elements and I don't think that at that point any postprocessing is done. Also, if it's supposed to be done I guess it requires another intermediate buffer to first scale the image and then dither the result and not the input.

Waiting for dpJudas's input here. In any case, I think this is worth evaluating the existing options and their costs.

Well, I am not hard pressed about that. If we can't get it in after the scaling, then that's how it currently works in mod form anyhow. It doesn't look as good with the scaling but, it doesn't look terrible, either.

The Present shader would be the natural place if it should be done post resolution scale. It can use the gl_ScreenPos variable to make it full resolution (as opposed to using UV coords). It still has the input as half-floats and outputs to the frame buffer. The catch is this is after the 2D HUD, which could maybe make the dithering more visible to the eye.

Creating a separate render buffer at full resolution before the 2D HUD will be a bit too problematic I think. So IMO its either the Present shader or like in Rachael's current implementation.

There's actually two issues with where it is located now:

1. The aforementioned resolution scaling.
2. The screen blend which is done as the first thing in the 2D pass.