Max GUI scale/Splitscreen HUD squish convars V2

This merge requests adds 3 new convars, related to HUD/GUI scaling:

• "gui_maxscale" - The global max HUD/menu GUI/title screen logo scale multiplier. For example, a window size of 1920x1080 would by default have a GUI scale of 5, but this convar can limit it to less than 5 if a user wants, although not more than 5 unless the window size is increased.

• "gui_maxscale_splitscreen" - The max HUD scale multiplier specifically for splitscreen graphics (anything with V_PERPLAYER while in splitscreen). Note that this is currently limited to no more than "gui_maxscale", but I don't see why one would want the HUD to be bigger in splitscreen, so that's probably fine.

• "gui_squish_splitscreen" - Whether or not to squish the splitscreen HUD to half height, as in v2.2.0. Defaults to squishing.

Minor extra goodie: MAXGUISCALE is a new (non-Lua/-SOC-accessible) constant, defined at compile-time based on BASEVIDWIDTH/MAXVIDWIDTH and BASEVIDHEIGHT/MAXVIDHEIGHT, to avoid "6" being a magic number in GUI-scale-related contexts. There are likely many things that still use "6" instead of MAXGUISCALE, however.

The "maxscale" convars can range from 0 up to MAXGUISCALE, with 0 (the default) disabling the limit. The splitscreen HUD squishing is also enabled by default, matching v2.2.0 behaviour/appearance. Note that the "maxscale" convars are absolute multiplier limiters, not a ratio of the current window size, which is part of the reason that they're console-exclusive "advanced" things rather than something accessible through options menus.

I've tested this in both the Software and OpenGL renderers with local 64-bit builds, and all vanilla and Lua-based HUD/GUI drawing seems appropriately affected.

If you want to test this, a 64-bit build for Windows, built using MinGW64, based on commit 27285365, can be found here.

Version 2 "changelog": I made a merge request for this a day earlier too, however it had a big oversight in that splitscreen HUD wouldn't be aligned properly in "aspect-correct"/"green" resolutions when the GUI was at full scale. I've fixed that now, and everything now stays properly aligned in different aspect ratios and scalings. I've also linked to a 64-bit build of this, for easy download-and-test-ing if that's wanted.

mentioned in commit Zwip-Zwap_Zapony/SRB2@95282f70

mentioned in commit Zwip-Zwap_Zapony/SRB2@354f85ae

mentioned in merge request !621 (closed)

added 1 commit

• 7c43ae09 - Change gui_maxscale's "0" from "MIN" to "Default"

Compare with previous version

added 1 commit

• 926266e2 - Remove commented-out max title screen logo scale

Compare with previous version

mentioned in commit Zwip-Zwap_Zapony/SRB2@49d2bbfb

This has been confirmed by Latius to affect Lua HUD stuff appropriately. And I don't have specific plans for anything more with this, so this merge request is probably ready for review now.

changed the description

I'm not sure how I feel about forcing scripters to take even more factors in account when creating extra HUDs.

Many of them already fail at supporting most resolutions properly, I highly doubt it'll make things easier if now they also have to make extra calculations to guess the position of the vanilla HUD according to the GUI scale, splitscreen mode and whatnot.

Scripters don't really have to take more factors into account. They just have to make sure to use the V_SNAPTO-flags appropriately, which they should also do to correctly support "non-green" resolutions even without this being merged.

I had Latius test this out with some Lua HUD stuff that they already had, and besides two instances of improper V_SNAPTO-flagging (which would affect "non-green" resolutions too), which they then fixed in their Lua script afterwards, everything worked perfectly, scaling and aligning correctly.

Granted, I didn't have Latius test split-screen mode with "gui_squish_splitscreen" disabled nor "gui_maxscale_splitscreen" changed about, but if "gui_maxscale" works on Lua HUD stuff in the same way as it does on vanilla HUD/GUI stuff, then "gui_maxscale_splitscreen" and "gui_squish_splitscreen" should work on Lua HUD stuff too (as long as the V_PERPLAYER flag is used on the graphic), and those things work fine for vanilla HUD stuff.

TL;DR: Scripters don't have to worry about this, this is all automatically-handled.

I checked and indeed it seems that 2.2 does make use of the V_SNAPTO flags for most of its HUD elements, instead of using complicated formulae like in 2.1, so indeed most HUD scripts should work without major changes.

I should probably mention that this merge request does indirectly introduce a few unpleasantnesses, when coupling a high game resolution with a low GUI scale. [Image]

• HUD/GUI stuff that extends past the edge of the screen may have their cutoff points visible. Notable examples include the zig-zag graphics for act title cards and single-player character selection. (This can be worked around by using graphics that are more than 1920 pixels wide and/or 1200 pixels tall in those places, if applicable. A better option would be "looping" graphic-drawing functions, but that requires code changes, not just asset changes.)

• The single-player character selection screen only shows 3 characters at a time, even if more than 3 character "slots" can be seen. (This would need code changes to be fixed.)

• The black blindfold fill in Hide & Seek in split-screen is affected by GUI scaling. This is also a problem even in v2.2.0, when using any "non-green" game resolution, just to a lesser extent. (This issue does NOT affect online multi-player! The blindfold stays full-screen in online multi-player, at all times, at any GUI scale. So don't worry about this being used to cheat online.)

I'd still wager that the pros far outweigh the cons in this case, however, especially as these issues are not a direct result of this merge request. (The "pros" are being able to set a GUI scale that suits one's desires, including using a GUI scale of 4 for better texel size consistency at 1920x1080 than the default 5, for example, and being able to un-squish the split-screen HUD.)

The first and second issue mentioned above also don't happen by default with this merge request, only if a user manually inputs a low max GUI scale. Even without this merge request, they'd still happen with sufficiently tall-but-skinny custom resolutions.

Please don't let these things impact this merge request's chance of being merged. It'd just be wrong for me to not mention them.

I'm going to re-do this merge request at some point. There seem to be a few minor quirks still, and I plan on doing some internal improvements/changes too, so for now, I'll close this merge request (and then make a new one when I re-done this).

closed