FogDensity support in the software renderer
Moderator: GZDoom Developers
FogDensity support in the software renderer
It seems that FogDensity stuff doesn't work in the software renderer... can it be added?
Re: FogDensity support in the software renderer
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.
This would take some time to implement, at best.
Re: FogDensity support in the software renderer
Understood... I don't need it urgently, so take your time.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: FogDensity support in the software renderer
This won't be easy because more information needs to go into the actual drawers which the software renderer does not handle.
Re: FogDensity support in the software renderer
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.
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.
Re: FogDensity support in the software renderer
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.
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.
Re: FogDensity support in the software renderer
Indeed -- The Adventures of Square in particular uses a hand-tweaked colormap to make overbright colors fade to their saturated counterparts, like so: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.
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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: FogDensity support in the software renderer
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.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.
Re: FogDensity support in the software renderer
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."
I mean, if anyone has any ideas, be my guest, but I didn't expect this notion to be anything other than "magic."
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: FogDensity support in the software renderer
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.
- zrrion the insect
- Posts: 2411
- Joined: Thu Jun 25, 2009 1:58 pm
- Location: Time Station 1: Moon of Glendale
Re: FogDensity support in the software renderer
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?
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: FogDensity support in the software renderer
That's not how OpenGL works. It's also far from foolproof.