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.
This reuses the FTexCoordInfo class the hardware renderer had been using to calculate wall texture offsetting.
The software renderers still need this sorted out to bring them in line with the rest of the code, though, but they do not have this code sufficiently well organized to make this a straightforward task.
This will now both exclude floor caps when only ceiling elements are used and everything outside the bounding box of active portal lines.
Hopefully this is enough to fix the issues with portal caps but of course it is not foolproof if someone just makes the right setup.
The main reason is to unify the portal hierarchy again. The split into a hardware independent and a hardware dependent part turned out to be unnecessary and complicated matters.
Another issue was that the new stencil setup code was having a few subtle problems, so this recreates the original ones with indirect API calls.
* 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.
Until now this wasn't doable because these could have come from hw_FakeFlat which only were local copies on the stack.
With the recent change these faked sectors live long enough so that they can be passed around here.
An exception is made for the sprite drawer which needs to call this in the worker thread on some occasions for as-yet unprocessed sectors.
This case may not alter the cache to avoid having to add thread synchronization to it.
The main reason for this change is that pointers to such manipulated sectors can now be considered static in the renderer.
Due to them being short lived local buffers it was not possible to carry them along with the render data for information retrieval.
This portal got fixed in a later re-release of KDiZD and no other portal needs this runtime fix to my knowledge.
The main problem here is that this runtime fix requires some manipulation of the render data that does not work anymore.
Should other maps need this fix as well they are probably best served with a compatibility entry.
This also removes one piece of code that was used to cope with the missing clip planes on old ATI cards, so support for those will most likely have to be dropped in the near future.
A section is a continuous part of a sector or in some case of several nearby continuous parts. For sectors with far away parts multiple sections will be created, especially when they lie in disjoint parts of the map.
This is mainly supposed to cut down on time for linking dynamic lights. Since they need to traverse subsectors to find all touching sidedefs a more coarse data structure that only contains the info needed for this is more suitable. In particular, this does not contain any intra-sector lines, i.e. those with both sides in the same sector.
src/hwrenderer/dynlights/hw_lightbuffer.h:51:29: warning: comparison between signed and unsigned integer expressions
[-Wsign-compare]
src/hwrenderer/scene/hw_renderstate.h:196:44: warning: operation on '((FRenderState*)this)->FRenderState::mVertexOffsets[0]' may
be undefined [-Wsequence-point]
I thought this wasn't needed but apparently the buffer refactoring caused this not to be done automatically anymore.
Best have it once at the start of each frame where the cost is negligible.
Since the job nodes were already taken from a static array, the added linked list isn't really needed. All we need is a read and a write pointer into the array, This can even be done without a spinlock as long as we assume that the list never overflows.
This is not flexible enough. There was already one place where this was not supposed to go through the render state.
The new interface allows more general use of the contained buffer objects.
The original idea was to let Vulkan do this completely differently, but if that comes to pass it should be done without having generic data maintenance code on the API side.
