[3.5.1] HUD cameratextures don't work in software

Is there something that doesn't work right in the latest GZDoom? Post about it here.

Moderator: GZDoom Developers

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!
User avatar
Matt
Posts: 9696
Joined: Sun Jan 04, 2004 5:37 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Debian Bullseye
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
Contact:

[3.5.1] HUD cameratextures don't work in software

Post by Matt »

_mental_'s test zip here works for this too.

1. Run that thing.
2. Switch to software mode.

Expected: Cameratexture shows the camera in software mode.
Actual: Cameratexture frozen in whatever it was showing when you made the change. If you restart GZDoom while in software, it's just black.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: [3.5.1] HUD cameratextures don't work in software

Post by Graf Zahl »

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.
Post Reply

Return to “Bugs [GZDoom]”