Incorrect rendering of some top right icons

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!

Incorrect rendering of some top right icons

Postby theleo_ua » Sat Nov 30, 2019 2:10 pm

GZDoom 4.2.4 x64
Windows 7 Ultimate x64

Incorrect rendering of some top right icons (some frames are very wide or very thin): https://my.pcloud.com/publink/show?code ... PQk5I4SJ3k


Steps to reproduce:

1) Launch gzdoom with hexen.wad as iwad

2) Start first map (hxvisit 01)

3) click INDIANA cheat

4) use icon of the defender item

5) use boots of speed item

Expected result: top right icon proportions are always the same, icons rendered correctly as in vanilla: https://my.pcloud.com/publink/show?code ... by9HtGWdwV

Actual result: top right icon proportions are not always the same, icons rendered incorrectly (some frames are very wide or very thin): https://my.pcloud.com/publink/show?code ... PQk5I4SJ3k


NOTE: If you cannot reproduce this, then there is a small chance that my gzdoom config is required, so here it is (for any case): https://my.pcloud.com/publink/show?code ... x4T8WmTz6y

NOTE 2: Only icon of the defender and boots of speed are affected. All other icons (wings of wrath and dark servant) are rendered correctly in my case
User avatar
theleo_ua
 
Joined: 07 Feb 2016

Re: Incorrect rendering of some top right icons

Postby Player701 » Wed Dec 18, 2019 9:21 am

This issue manifests only in the alternative HUD. Some frames of these icons look distorted because not all of them are of the same size. The method AltHud::DrawImageToBox forces them into a fixed-size box; to perform this operation, the method also needs to know the texture's width and height. To retrieve them, it calls TexMan::GetScaledSize, which always returns the size of the first frame. As a result, if the size of the current frame is not the same as the size of the first frame, that frame will not be drawn as expected.

Ultimately, this means that in any drawing operation, calculations that depend on the properties of a texture might not always be valid when the texture is animated and at least one frame has a different size than the rest. Some way to access the properties of the current animation frame should be made available.

IMO, there are at least two ways to resolve this:

  1. Add a method to TexMan to allow retrieving the current frame of an animated texture (the animation is defined by the name of its first frame). Rewrite AltHud::DrawImageToBox to use this method. IMO, this is not a very clean solution, since it basically fully exposes the animation abstraction to user code, forcing the user to deal with it entirely manually. It also undermines the purpose of the DI_DONTANIMATE flag for BaseStatusBar::DrawImage/DrawTexture and the "animate" argument of Screen::DrawTexture.
  2. Add an extra bool argument to all TexMan methods that retrieve the properties of a texture to take animation into account. If the argument is true, the requested parameter(s) (size, offsets etc.) are returned for the current animation frame instead of the requested texture. This will require more work to be done on the engine side, but in the end dealing with animated textures will be more transparent for the user.
I'm not very familiar with the texture subsystem in the engine, so I have no idea how hard it might be to implement any of the above. Perhaps there is an even better solution which I've overlooked.

UPD: Further analysis based on the research of the corresponding parts of the source code:

The implemenations of most of TexMan's methods rely on FTextureManager::ByIndex, which already has an animate parameter built into it. Looking at how it's implemented, both solutions 1 and 2 are feasible implementation-wise. However, solution 1 would require altering existing code that makes use of TexMan. Solution 2 could avoid that by introducing an "animate" argument to the following methods, all of which make use of ByIndex internally:

  • GetName
  • GetSize
  • GetScaledSize
  • GetScaledOffset
  • CheckRealHeight
If the new argument is set to true by default, then existing code need not be fixed. However, it might lead to breakage of user code that draws textures with animation disabled. This can be counteracted by versioning the change (if possible).
User avatar
Player701
 
Joined: 13 May 2009
Location: Russian Federation
Discord: Player701#8214
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Incorrect rendering of some top right icons

Postby _mental_ » Thu Dec 19, 2019 9:50 am

The second approach is better in my opinion. Although, animate argument should be set to false by default. AltHud.DrawImageToBox() needs to pass its argument to TexMan.GetScaledSize().

This will fix wrong aspect ratio of powerup icons, but won't change incorrect placement inside designated space, DI_SCREEN_RIGHT_TOP vs. DTA_CenterBottomOffset.
Hexen speed boots is a good example of this. The rotating icons will "jump" from frame to frame.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Incorrect rendering of some top right icons

Postby Graf Zahl » Thu Dec 19, 2019 10:05 am

I think the only way to address this is to calculate a common bounding box for the entire animation. Too bad that this was never considered to be a feature of the renderer, these animated icons weren't even designed as animated textures, that was something ZDoom added later.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Incorrect rendering of some top right icons

Postby Player701 » Thu Dec 19, 2019 12:54 pm

Graf Zahl wrote:I think the only way to address this is to calculate a common bounding box for the entire animation.

Hmm. Yes, it would seem so. If a frame has a different size than the rest, it might also be scaled in a different way. As a result, the proportions will be correct but relative sizes might not be the same, and the animation sequence will look weird.

However, I still suggest to introduce a way to retrieve the properties of the current animation frame (see proposal #2 above). It will certainly prove useful in mod code where these properties (for example, offsets) are part of the calculations. If this is now considered to be out of scope for this report, I can provide a PR later.
User avatar
Player701
 
Joined: 13 May 2009
Location: Russian Federation
Discord: Player701#8214
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Incorrect rendering of some top right icons

Postby Graf Zahl » Thu Dec 19, 2019 1:03 pm

The main problem here is that 'current animation frame' doesn't mean anything. The animation ticker runs independently of the playsim so whatever you get may already have changed when you draw it. In general, animations with varying frame sizes are essentially an unimplemented and undefined feature unless a normalized bounding box is used - and used consistently.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Incorrect rendering of some top right icons

Postby Player701 » Thu Dec 19, 2019 1:31 pm

Oh. That complicates matters indeed. There wouldn't be a reliable way to make use of the texture's properties if they can suddenly change at any time. Some form of synchronization is probably necessary.
User avatar
Player701
 
Joined: 13 May 2009
Location: Russian Federation
Discord: Player701#8214
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Incorrect rendering of some top right icons

Postby Graf Zahl » Thu Dec 19, 2019 2:02 pm

There is no synchronization. Animated textures only work as intended if all frames have the same size and origin.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Incorrect rendering of some top right icons

Postby Player701 » Thu Dec 19, 2019 2:05 pm

Then these particular textures themselves should be fixed. Isn't it possible to achieve this via a TEXTURES definition?
User avatar
Player701
 
Joined: 13 May 2009
Location: Russian Federation
Discord: Player701#8214
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Incorrect rendering of some top right icons

Postby Graf Zahl » Thu Dec 19, 2019 2:11 pm

Yes, and that's what I had already in mind. Fortunately this is strictly ZDoom stuff
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Incorrect rendering of some top right icons

Postby Player701 » Thu Dec 19, 2019 2:22 pm

Well, if the restriction that all frames must have the same size and offsets is to be kept, then I don't have any more concerns. :)
User avatar
Player701
 
Joined: 13 May 2009
Location: Russian Federation
Discord: Player701#8214
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Incorrect rendering of some top right icons

Postby theleo_ua » Thu Dec 19, 2019 2:56 pm

Player701 wrote:Then these particular textures themselves should be fixed. Isn't it possible to achieve this via a TEXTURES definition?


Does this fix will work even with hires packs, for example neural hexen pack?

Also could you please accept my request in discord (want to ask something)
User avatar
theleo_ua
 
Joined: 07 Feb 2016


Return to Bugs

Who is online

Users browsing this forum: No registered users and 1 guest