All decisions were done deep inside the texture creation code, leaving zero options to the higher level code for controlling the feature.
Changed this so that the option to upscale must be passed as a parameter to FRenderState::SetMaterial and extended all needed variables to manage the added texture variants.
Still not solved: Material layers need explicit control, not only for scaling but also for filtering.
* 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.
* moved the sprite renaming out of the file system entirely into a caller-provided callback.
* renamed several functions to closer match the terms of a file system.
* moved the VM interface out of the implementation.
There is no chance that Apple will fix their OpenGL drivers
The only viable solution is to preprocess these functions out, and put zeroes instead of them
ERROR: 0:95: Use of undeclared identifier 'uTextureModulateColor'
ERROR: 0:104: Use of undeclared identifier 'uTextureAddColor'
ERROR: 0:107: Use of undeclared identifier 'uTextureModulateColor'
...
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.
This shouldn't be in the hardware independent interface because the semantics on OpenGL and Vulkan are too different, so a common implementation is not possible.
Most bind calls were in the GL interface anyway, so these no longer pass through hardware independent code.
This also moves the bind calls in the shadowmap code into the GL interface - these never did anything useful in Vulkan and aren't needed there.
Last but not least, this moves the legacy buffer binding handling into FGLRenderState and performs the initial binding for the light buffer in a more suitable place so that this doesn't have to pollute the render state.
Vulkan hardware buffer for software canvas may have some padding
Software renderers should be aware of buffer's pitch in order to copy pixels properly
https://forum.zdoom.org/viewtopic.php?t=64562
