This worked in some instances but it also broke attenuated lights in other instances, and also caused the shaders to fail to compile on Mac.
This reverts commit 679518f8e5.
Apparently with checking uLightLevel the shader cannot discard the slow software lighting path entirely adding a significant amount of processing time.
Changed to check the actual lightmode value, which re-enables the fast path again.
For GZDoom this is completely disabled, of course, because the Doom engine does not need it, but in order to have the same backend code in both engines it needs to be present.
* handle brightmaps in the main shader instead of keeping separate instances around.
* added detail and glow layers from Raze.
* fixed material setup which could not guarantee that everything was initialized correctly.
* for warped textures, warp all layers. With this brightmaps finally work on warped textures.
Note: Vulkan reports a "device lost" error with this which still needs to be investigated.
It makes little sense exposing every minute detail of this through UDMF.
Setting it up that way is far too complicated. Using virtual textures that map to a real texture plus a colorization record should be far easier to use by mappers.
This also doesn't piggyback on the Doom64 color feature anymore and is completely separate, despite some redundancies.
This is still missing the texture definition part, though.
Aside from adding an additive component it can now also do:
- desaturation (not limited to the range of 0..1 so it can also be used for oversaturation by applying a negative number or negative saturation by going above 1.0.
- invert the texture
- apply a blend, including 3 special mode taken from EDuke32.
Currently only the implementation is done, it is not exposed to UDMF yet.
Unlike uObjectColor2, this is more global state. uObjectColor2 is part of gradient calculation which may later be offloaded to a secondary buffer which already resulted in only conditionally setting it, resulting in broken special colormap application for the software renderer.
Rename ColorAdd to AddColor
Add AddColor to FRenderState
Tweak SpecialColors array in ZScript to include the additive color
Add uAddColor to the shader compiler
Add uAddColor to the texel
* Colors can npw be defined per sidedef, not only per sector.
* Gradients can be selectively disabled or vertically flipped per wall tier.
* Gradients can be clamped to their respective tier, i.e top and bottom of the tier, not the front sector defines where it starts.
The per-wall colors are implemented for hardware and softpoly renderer only, but not for the classic software renderer, because its code is far too scattered to do this efficiently.
Although this doesn't look as good as the PCF version it is a lot less calculation intensive and therefore more suitable for weaker hardware.
It also tends to bleed through walls a lot less.
