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.
- clamp scissors fully to avoid NVidia's awful drivers locking up the entire system if they end up out of bounds
- perform buffer clears as part of the render pass. this puts some restrictions on how FRenderState.Clear can be used
- add an offset uniform to the present shaders so the vulkan target can flip the image during presentation
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.
