Incorrect rendering of some top right icons
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!
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!
- theleo_ua
- Posts: 162
- Joined: Sun Feb 07, 2016 11:38 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Location: Ukraine
- Contact:
Incorrect rendering of some top right icons
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
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
- Player701
-
- Posts: 1640
- Joined: Wed May 13, 2009 3:15 am
- Graphics Processor: nVidia with Vulkan support
- Contact:
Re: Incorrect rendering of some top right icons
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:
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:
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:
- 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.
- 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.
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
Re: Incorrect rendering of some top right icons
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.
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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Incorrect rendering of some top right icons
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.
- Player701
-
- Posts: 1640
- Joined: Wed May 13, 2009 3:15 am
- Graphics Processor: nVidia with Vulkan support
- Contact:
Re: Incorrect rendering of some top right icons
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.Graf Zahl wrote:I think the only way to address this is to calculate a common bounding box for the entire animation.
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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Incorrect rendering of some top right icons
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.
- Player701
-
- Posts: 1640
- Joined: Wed May 13, 2009 3:15 am
- Graphics Processor: nVidia with Vulkan support
- Contact:
Re: Incorrect rendering of some top right icons
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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Incorrect rendering of some top right icons
There is no synchronization. Animated textures only work as intended if all frames have the same size and origin.
- Player701
-
- Posts: 1640
- Joined: Wed May 13, 2009 3:15 am
- Graphics Processor: nVidia with Vulkan support
- Contact:
Re: Incorrect rendering of some top right icons
Then these particular textures themselves should be fixed. Isn't it possible to achieve this via a TEXTURES definition?
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49071
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Incorrect rendering of some top right icons
Yes, and that's what I had already in mind. Fortunately this is strictly ZDoom stuff
- Player701
-
- Posts: 1640
- Joined: Wed May 13, 2009 3:15 am
- Graphics Processor: nVidia with Vulkan support
- Contact:
Re: Incorrect rendering of some top right icons
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.
- theleo_ua
- Posts: 162
- Joined: Sun Feb 07, 2016 11:38 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Location: Ukraine
- Contact:
Re: Incorrect rendering of some top right icons
Does this fix will work even with hires packs, for example neural hexen pack?Player701 wrote:Then these particular textures themselves should be fixed. Isn't it possible to achieve this via a TEXTURES definition?
Also could you please accept my request in discord (want to ask something)