Welcome to the ZDoom Forums!

It seems that FogDensity stuff doesn't work in the software renderer... can it be added?

Not without refactoring the diminishing light code. As it is right now a sector's brightness is literally the "fog amount".

This would take some time to implement, at best.

Understood... I don't need it urgently, so take your time.

This won't be easy because more information needs to go into the actual drawers which the software renderer does not handle.

Well the software renderer can handle it with the existing drawers just by creating new colormap sets - but that's going to be a royal pain for the palette renderer when it has to continually create new colormaps to accomodate the new brightness+fog levels.

In fact, it might be a good time to consider removing the palette drawers' dependence on such things and move the entire COLORMAP system to a compatibility slate (where it is only shown if it's there, and if the usual "fog 00 00 00 + sector.color ff ff ff" rules apply). The RGB256k system can be used in place of colormaps and can even create more than 32 brightness levels, but after such a thing is implemented there will be a noticeable slowdown with the drawers since its lookups will be less sequential than they were using a simple colormap table.

Doing that will make the software renderer look like the softpoly 8-bit mode. Most of those running the 8-bit mode doesn't want better graphics - if they did, they wouldn't be using the palette mode.

Edit: just realized I remembered wrong how I implemented softpoly 8-bit. It still uses the colormaps for the fog, which is on purpose to maintain the proper gradients as I assume the 8-bit crowd wants.

dpJudas wrote:It still uses the colormaps for the fog, which is on purpose to maintain the proper gradients as I assume the 8-bit crowd wants.

Indeed -- The Adventures of Square in particular uses a hand-tweaked colormap to make overbright colors fade to their saturated counterparts, like so:


It's pretty essential to the look of the game, and is the reason we still support and recommend the 8-bit renderer despite color-banding and GPU ubiquity. Now if there was some way of achieving the same sort of thing in GL? Absolutely -- that that's perhaps off-topic now.

Xaser wrote:Now if there was some way of achieving the same sort of thing in GL? Absolutely -- that that's perhaps off-topic now.

How? Something that's white is just white and not yellow. For that you'd need unclamped input colors. The required color information is already lost in the source palette and cannot magically be restored.

That question was mostly rhetorical. I don't know how one would achieve such a thing aside from going full 8-bit emulation where graphics are downsampled to palette and the indices are used to pick fade data from the colormap. I don't know enough about OpenGL/etc. to know whether such a thing is feasible in GPU-land, though, so I have to defer to the experts on this.

I mean, if anyone has any ideas, be my guest, but I didn't expect this notion to be anything other than "magic."

OpenGL is not capable of adding color where none is, i.e. if you got white (255, 255, 255) any attempt to manipulate the color will result in a variation of gray. To get yellow - especially a brighter yellow - you'd have to use an overbright palette, i.e. 512, 512, 255, to have something that looks white but when darkened becomes yellow. Such a thing is currently not supported.

You might be able to get a sample of the colours around white pixels in a texture/sprite and fade based on the hues of those colours?

That's not how OpenGL works. It's also far from foolproof.