This should be less of a drag on the playsim than having each light a separate actor. A quick check with ZDCMP2 showed that the light processing time was reduced to 1/3rd from 0.5 ms to 0.17 ms per tic.
It's also one native actor class less.
The new specification is more flexible, and allows assigning additive
colors to individual parts of a sector (walls, sprites, flats) and even
individual parts of a side (top, middle, bottom)
Add AdditiveColors arrays to sector_t and side_t::part
Initialize AdditiveColors arrays to 0
Export AdditiveColors to ZScript
Save AdditiveColors in saved game files
Use colors from AdditiveColors arrays when setting the additive color
for the render state
Add code to parse the new UDMF additive color properties
Remove additive color slot from sector color/part enum
Add SetAdditiveColor to sector_t and side_t
Add GetAdditiveColor to side_t
Export new methods and additive color arrays to ZScript
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
This did no longer sort sprites in the same position reliably since the feature to render sprites which only partially are inside a sector was added.
With this, sprites in the same position are no longer guaranteed to be added to the render list in sequence.
Fixed by adding an 'order' field to AActor which gets incremented with each spawned actor and reset when a new level is started.
The software renderer will also need a variation of this fix but its data no longer has access to the defining actor when being sorted, so a bit more work is needed here.
This is essentially a stripped down version of FHardwareTexture, which can exist on the API independent size, and which stores pointers to hardware textures instead of OpenGL texture handles.
This will mostly ensure that each patch used for composition is only loaded once and automatically unloaded once no longer needed.
So far only for paletted rendering, but the same logic can be used for true color as well.
* split up FMultiPatchTexture into a builder class and the actual image source.
* since images can now be referenced by multiple textures the old redirection mechanism has been removed. It can be done better and less intrusive now. Simple single patch textures already directly reference the underlying patch image now.
* allocate all image source related data from a memory arena. Since this is all static this makes it a lot easier to free this in bulk.
This was done to make reviewing easier, again because it is virtually impossible to search for the operators in the code.
Going through this revealed quite a few places where texture animations were on but shouldn't and even more places that did not check PASLVERS, although they were preparing some paletted rendering.
This class has only meaning for software-based warping so it doesn't have to be a part of the FTexture hierarchy.
Making it a subclass of FSoftwareTexture is fully sufficient.