This was leaking memory with being handled like a regular image texture and also would prevent further changes to the in-game texture handling because the savegame picture was imposing some limitations on FPNGTexture's implementation
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.
For ad-hoc Dehacked state functions no ArgFlags are created, in this case they can just be assumed to not be relevant here, because none of these function produces reference arguments.
Initially, settings controller flag was false by default
It was not touched during construction and destruction of player_t instances though
Now, with all members initialized in class definition, this flag must be saved and restored manually
https://forum.zdoom.org/viewtopic.php?t=62830
FDummyTexture had a big problem: Whenever it was accessed by accident it crashed the app because it wasn't fully implemented.
What it should do is return empty pixels of the given size, and an unextended FImageTexture is doing just that.
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.
In ZDoom this would affect everything using a patch that got used in a front sky layer, even if the texture was totally unrelated. It is only owed to the low usability of such patches for other purposes that this hasn't caused problems.
Previously it tried to copy all patches of composite sub-images directly onto the main image.
This caused massive complications throughout the entire true color texture code and made any attempt of caching the source data for composition next to impossible because the entire composition process operated on the raw data read from the texture and not some cacheable image. While this may cause more pixel data to be processed, this will be easily offset by being able to reuse patches for multiple textures, once a caching system is in place, which even for the IWADs happens quite frequently.
Removing the now unneeded arguments from the implementation also makes things a lot easier to handle.
* it's no longer the main texture objects managing the pixel buffer but FSoftwareTexture.
* create proper spans for true color textures. The paletted spans only match if the image does not have any translucent pixels.
* create proper warp textures instead of working off the paletted variants.
As a side effect, caching of pixel buffers for texture composition is temporarily disabled, as it management of texture redirections. These things will be reimplemented once things progress further. The existing methods here had their share of serious issues that should be fixed.
