HUD scaling options interact incorrectly with BeginHUD at higher resolutions

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Post Reply
User avatar
Jekyll Grim Payne
 
 
Posts: 1069
Joined: Mon Jul 21, 2008 4:08 am
Preferred Pronouns: He/Him
Graphics Processor: nVidia (Modern GZDoom)
Contact:

HUD scaling options interact incorrectly with BeginHUD at higher resolutions

Post by Jekyll Grim Payne »

If I'm calling BeginHUD(1., false, 640, 480), then I get the following behavior by using either 'User interface scale' or 'Fullscreen HUD' options under Scaling options:

- If GZDoom is in fullscreen, the above options will change the HUD size only every 2 increments (resolution or aspect ratio don't matter)
- If GZDoom is in a window, the above options will change the HUD size only every 4 increments (I have a 21:9 screen so I could only test on that)


Here's a video I posted earlier in ZDoom Discord that showcases the fullscreen issue: https://cdn.discordapp.com/attachments/ ... -04-02.mp4

This can be recreated with the attached HUD (which is a copy of DoomStatusBar but with only the fullscreen bit; it calls BeginHUD() with 640x400 instead of the default values).

STR:
- Load GZDoom with -file HUDScaleIssue.zip
- Make sure you're using fullscreen HUD, and the Alternative HUD is disabled
- Navigate to Scaling Options > User interface scale or Fullscreen HUD
- Change the values

Note, this bug (or whatever it is) is fixed if I apply scaling to the BeginHUD() call manually by reading the hud_scale value:

Code: Select all

// in the HUD's Draw() call:
        vector2 hudres = (640, 400);        
        CVar userHudScale = CVar.GetCVar('hud_scale', CPlayer);
        int userscale = Clamp(userHudScale.GetInt(), -1, 8);
        if (userscale > 0.)
            hudres /= userscale;
        
        BeginHUD(1., true, int(hudres.x), int(hudres.y));
Attachments
HUDScaleIssue.zip
(1.79 KiB) Downloaded 22 times
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49066
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: HUD scaling options interact incorrectly with BeginHUD at higher resolutions

Post by Graf Zahl »

The main problem here is that hud_scale is a major design disaster. It was designed to set a clean scaling factor for 320x200 content so for larger HUDs it does not work right.
Since this thing is quite shit I added a new, properly implemented alternative using hud_scalefactor. However, since this is not compatible with the old implementation there is a toggle cvar to switch between both modes, called hud_oldscale.

The downside of the new algorithm is that it can not guarantee clean scaling and seeing what kind of hubbub it caused when the main menu was given proper scaling capabilities (i.e. many custom menus were poorly designed and not tested on all screen sizes) the default is still the old functionality.

If you now go ahead and check hud_scale yourself you are actually breaking the HUD for all users of the new, linear scaling algorithm.
User avatar
Jekyll Grim Payne
 
 
Posts: 1069
Joined: Mon Jul 21, 2008 4:08 am
Preferred Pronouns: He/Him
Graphics Processor: nVidia (Modern GZDoom)
Contact:

Re: HUD scaling options interact incorrectly with BeginHUD at higher resolutions

Post by Jekyll Grim Payne »

Graf Zahl wrote: Sat Jan 14, 2023 10:21 am If you now go ahead and check hud_scale yourself you are actually breaking the HUD for all users of the new, linear scaling algorithm.
Well, that's a shame, but considering the majority of regular users are likely not aware of that feature and just have that stuff set to the default value, I don't see a way around it. I could just as well introduce a custom scaling CVAR instead...

I can check for the value of hud_oldscale and then just not apply my bandaid solution, though.

P.S. Also, currently if I have hud_oldscale set to false, none of the scaling options seem to do anything at all for me (that includes the HUD, even though I'm not setting forcescaled to true). Not sure what I'm missing here.
yum13241
Posts: 781
Joined: Mon May 10, 2021 8:08 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): EndeavorOS (basically Arch)
Graphics Processor: Intel with Vulkan/Metal Support
Contact:

Re: HUD scaling options interact incorrectly with BeginHUD at higher resolutions

Post by yum13241 »

Graf Zahl wrote: Sat Jan 14, 2023 10:21 am The main problem here is that hud_scale is a major design disaster. It was designed to set a clean scaling factor for 320x200 content so for larger HUDs it does not work right.
Since this thing is quite shit I added a new, properly implemented alternative using hud_scalefactor. However, since this is not compatible with the old implementation there is a toggle cvar to switch between both modes, called hud_oldscale.

The downside of the new algorithm is that it can not guarantee clean scaling and seeing what kind of hubbub it caused when the main menu was given proper scaling capabilities (i.e. many custom menus were poorly designed and not tested on all screen sizes) the default is still the old functionality.

If you now go ahead and check hud_scale yourself you are actually breaking the HUD for all users of the new, linear scaling algorithm.
Is this related to why QC:DE's menu breaks ("Quit Game" is off screen on a 1366x768 screen) if "Disable Menu Clean Scaling" is false? (double negative, IK)
Post Reply

Return to “Closed Bugs [GZDoom]”