by Graf Zahl » Thu Nov 01, 2018 5:21 am
Unfortunately, this is a problem where the current texture hierarchy implementation totally stands in the way.
As things stand, the 2D drawer and all underlying code needs to access the canvas texture in two entirely different ways depending on the active renderer and none of the code is prepared to do that. Most of that comes from the original design of the texture class. When this was written (remember, this was in 2003 when there was no GZDoom to consider!) it was singlemindedly developed for the software renderer, so the hardware renderer had to tack on all its feature without really being able to sanitize the code.
As a result the entire texture creation code does not have sufficient state to handle this particular case without a real shitload of support code.
The big problem here is that in order to change the texture implementation the software renderer has to receive extensive changes because it has zero abstraction over the texture data. The data source and the provider for the render information are the same object which is just - sorry to say that - very bad design. This is particularly catastrophic for the canvas texture
The amount of work required to fix this is why I always steered clear of this issue.
Ideally this should be a three-stage approach: At the lowest level lie the data sources, i.e. one for each lump being used in a texture. They shouldn't bother with how their data gets used whatsoever. The texture should be a second layer on top of this, linking the data source with basic information like scaling, offsets, etc. And on top of that the actual layer that gets used by the renderer and forwards the info from the lower level classes in a usable way. Obviously this layer needs to be renderer specific - and currently only exists in the hardware renderer (i.e. the FMaterial class)
The lack of this kind of abstraction has led to an endless amount of errors over the years - I just fixed another one a few hours ago...
Bottom line: This is a job for later, and definitely not on my list of priorities.
Unfortunately, this is a problem where the current texture hierarchy implementation totally stands in the way.
As things stand, the 2D drawer and all underlying code needs to access the canvas texture in two entirely different ways depending on the active renderer and none of the code is prepared to do that. Most of that comes from the original design of the texture class. When this was written (remember, this was in 2003 when there was no GZDoom to consider!) it was singlemindedly developed for the software renderer, so the hardware renderer had to tack on all its feature without really being able to sanitize the code.
As a result the entire texture creation code does not have sufficient state to handle this particular case without a real shitload of support code.
The big problem here is that in order to change the texture implementation the software renderer has to receive extensive changes because it has zero abstraction over the texture data. The data source and the provider for the render information are the same object which is just - sorry to say that - very bad design. This is particularly catastrophic for the canvas texture
The amount of work required to fix this is why I always steered clear of this issue.
Ideally this should be a three-stage approach: At the lowest level lie the data sources, i.e. one for each lump being used in a texture. They shouldn't bother with how their data gets used whatsoever. The texture should be a second layer on top of this, linking the data source with basic information like scaling, offsets, etc. And on top of that the actual layer that gets used by the renderer and forwards the info from the lower level classes in a usable way. Obviously this layer needs to be renderer specific - and currently only exists in the hardware renderer (i.e. the FMaterial class)
The lack of this kind of abstraction has led to an endless amount of errors over the years - I just fixed another one a few hours ago...
Bottom line: This is a job for later, and definitely not on my list of priorities.