[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: 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.

[3.5.1] HUD cameratextures don't work in software

Postby Matt » Thu Sep 13, 2018 12:08 am

_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
Matt
Putting the XD into *xdeath since 2007
 
 
 
Joined: 04 Jan 2004
Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia

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

Postby Graf Zahl » Thu Nov 01, 2018 6: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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany


Return to Bugs

Who is online

Users browsing this forum: BLEX [Bot] and 2 guests