This particular case incorrectly factored in the sidedef's scaling factor for how to calculate the offset.
Fortunately this is a very rare case - a quick check yielded no maps depending on it.
Should any map surface that depends on this bug a compatibility option may be needed but it doesn't seem likely that this may be the case.
This particular case incorrectly factored in the sidedef's scaling factor for how to calculate the offset.
Fortunately this is a very rare case - a quick check yielded no maps depending on it.
Should any map surface that depends on this bug a compatibility option may be needed but it doesn't seem likely that this may be the case.
Between creation and resolving the texture manager will resort the textures and after that the old ids are no longer valid. The textures themselves have the correct one, so that should be used.
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.
