bugfix(gui): implement resolution scaling for unit health and info - #1607
bugfix(gui): implement resolution scaling for unit health and info#1607Mauller wants to merge 2 commits into
Conversation
|
|
||
| // do this so health bar doesn't get too skinny or fat after scaling | ||
| //healthBoxHeight = max(3.0f, healthBoxHeight); | ||
| healthBoxHeight = 3.0f; |
There was a problem hiding this comment.
The retrieved health box height from the object is already 3.0f, at higher resoutions this code prevents the health box from scaling relative to the vehicles and looks wrong. Which is why i removed it.
I reinstated the clamp on the max size of the health bar to prevent it shrinking too much when the resolution is scaled. This will also come into play more when zoom scaling is added.
Mauller
added
Bug
|
Is this a piece split off of #1573 ? |
Yes, this only implements the resolution scaling of the UI elements and some small fixes to the veterancy icon and compute health region code. I did not close the original as I will build the zoom scaling off this pr when finalised and merged. |
| @@ -2959,8 +2954,8 @@ void Drawable::drawContained( const IRegion2D *healthBarRegion ) | |||
| #else | |||
| Real scale = 1.0f; | |||
There was a problem hiding this comment.
It looks like EA already tried to do some scaling here with TheGlobalData->m_ammoPipScaleFactor in SCALE_ICONS_WITH_ZOOM_ML. Does SCALE_ICONS_WITH_ZOOM_ML still have any relevance? What does it do? If it is not useful, can that be removed before we add a new scaling for it?
There was a problem hiding this comment.
Scale icons with zoom does not have any real relevance once I properly implement the zoom scaling.
But the idea was to rescale the info icons as you zoomed into units so their size was kept uniform relative to the health bar. Which is what I reimplemented.
We could still make use of the pipscale factor though.
20904b1 to
09d6dae
Compare
|
Quick Rebase |
09d6dae to
d068267
Compare
|
Tweaked this now so the followup can implement user based options within InGameUI. This version also reduces the overhead a little since the scaling factor is only calculated once at initialisation and when the resolution gets changed. So with this, the unit info acts the same as with retail, but scales all the unit gui elements properly with resolution. |
d068267 to
a64a7ee
Compare
|
Moved the scale variable into the SCALE_ICONS_WITH_ZOOM_ML for the draw veterancy function |
a64a7ee to
c172cfe
Compare
|
Tweaked veterancy icon position, it should be in exactly the same place now, it might look slightly offset but that's actually the health bar being marginally shifted left due to the above mentioned change. |
|
Health bar size is not correct on higher solution. In 800x600, health bar is 1 pixel high. In 1600x1200 it is 4 pixels high.
|
Yes because it's scaling with the resolution, it's proportions are the same compared to 800x600 If the health bar remaind the same thickness as it is at 800x600 then you will barely see anything of it at higher resolutions. |
|
I think it is wrong. If health bar is 1px at 800x600, then it should be 2px at 1600x1200. |
Its not wrong, it's because of the way the health bar is setup. The border does not scale with the health bar and remains at only 1 pixel in height. The health bar region is 6 pixels high, which is double the default of 3 at 800x600, but there is always a 1 pixel border. This means that at 800x600 there is only a single pixel for the health bar info itself while theres 4 at 1600x1200 So overall the health bar is scaled properly, it's just that relatively more of the health bar is taken up by the border at 800x600 |
|
The other way to work this would be to also scale the health bar border at higher resolutions, it would also make the health bar more visible when health is getting depleted and should keep the health info itself scaled similar to 800x600 |
I think visually it should look twice as big. Right now it looks 4 times as big. |
I am working on something that should do that, some of the functions aren't working quite right for drawing rectangles with outlines so just currently investigating that. |
xezon
added
Enhancement
6ca0750 to
bdca8c3
Compare
|
Should be looking better now, ho ho ho. |
4b5bfae to
542f98b
Compare
542f98b to
f7f2ee4
Compare
d75242a to
33cdc71
Compare
33cdc71 to
58d6451
Compare
|
Quick rebase to catch up with main |
58d6451 to
335f413
Compare
|
Removed the changes from the extra commit and integer scale the health bar height now based on screen height scale. |
|
Is this ready for testing? |
|
|
||
| } | ||
|
|
||
| Real healthBoxWidth = healthBarRegion->width(); |
There was a problem hiding this comment.
The health bar is significantly wider than originally - at 16:9 aspect. Maybe more than twice as wide.
In principle widening is ok, because the original bar indeed looks narrow, but it looks too much in comparison. I expect this will cause complaints from long time players. I see this is mainly as pronounced in Wide Screen, so it looks like something was fixed that disproportionally affects Wide Screen Resolution. Perhaps make the default width closer to the original at 4:3 aspect (currently is a bit wider at 4:3) and then provide a User Option to scale the width, from 0 to N. This way user can fine the width to his preference, which likely will be required to satisfy taste.
Also, the fixed health bar shows a proper outline on damage, whereas the original was just one color. But this means visibility on the right side is a bit reduced. Maybe fill the right side of the health bar side with less transparency to somewhat preserve the original look more, but still show the outline. You can also play with the opacity of the outline to fine tune and compensate for visibility changes.
Left side is Original 1920x1080
Right side in Patched 1920x1080
Compared at about the same height.
There was a problem hiding this comment.
The health bar is wider because it is scaled to how it looks compared to 800x600
In the original health bar, the drawOpenRect function was broken meaning it was not properly drawing a rectangular border when it should have been. This is shown by the weird extra pixels under the bottom of the health bar and it not being perfectly rectangular.
The fixed outline makes it easier to see the amount of damage taken and gives it a much cleaner look.
There was a problem hiding this comment.
Yes it is fixed, which is good, but it is also now much different than the original in 16:9. And in 4:3 it is a bit wider than it used to be. This means we need to do something to give users the option to return to the original look, if they prefer it that way.
I say this, because this change would upset me to some degree and so I expect it can also cause upset for other players. And I am not even part of the super conservative group of people.
There was a problem hiding this comment.
if you compare 800x600 and 1600x1200 the width of the health bar is the same as retail compared to retail 800x600.
It is slightly shifted to the right due to fixes in the drawing of the health bar.
For scaling the UI elements, we were going to add the ability to change those in a followup PR, this PR was just to get things to scale up properly at higher resolutions in relation to 800x600 retail.
There was a problem hiding this comment.
Can you force scale it to retail now and unlock rescale with option in follow up change?
There was a problem hiding this comment.
Lets keep the scaling relative to what it was meant to look like at 800x600 in this change as originally discussed.
It would make the code awkward when trying to scale it to 1080p in this change.
I can add the user option to rescale things in one of the folloup PR's, that way users can adjust it and we can adjust the default scale value.
I still need to add zoom scaling and fix the bombed icon stuff after this PR as well as add the user scaling options.
|
|
||
| Real InGameUI::getUnitHealthbarScaleFactor() | ||
| { | ||
| return m_healthResolutionScaleFactor; |
There was a problem hiding this comment.
These scale factors are the preliminary work for adding user based scaling options, but i might tweak them a bit further in a followup PR when implementing that.
335f413 to
a482938
Compare
|
Just updated after recent zoom handling changes, had to tweak the zoom scaling factor to replicate the original health bar width values. This is ready to go otherwise. |
|
| Filename | Overview |
|---|---|
| Core/GameEngine/Include/GameClient/Display.h | Declares helpers for deriving display scaling from the default resolution. |
| Core/GameEngine/Source/GameClient/Display.cpp | Implements width and height resolution scale calculations. |
| GeneralsMD/Code/GameEngine/Source/GameClient/InGameUI.cpp | Initializes, calculates, and exposes unit-information resolution scale factors. |
| GeneralsMD/Code/GameEngine/Source/GameClient/Drawable.cpp | Applies scaling to unit health and information graphics and now safely guards veterancy rendering when its health region is unavailable. |
| GeneralsMD/Code/Libraries/Source/WWVegas/WW3D2/render2d.cpp | Adjusts outline line placement so scaled borders grow inward and meet at their corners. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart LR
Resolution[Current display resolution] --> Display[Display scale helpers]
Display --> InGameUI[Cached unit-info scale]
InGameUI --> Drawable[Unit icon and health-bar dimensions]
Drawable --> Render2D[Scaled fills, images, and outlines]
Options[Resolution change] --> InGameUI
Reviews (3): Last reviewed commit: "fix(gui): implement resolution scaling f..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
The floating health box and veterancy XP readout are sized in raw screen pixels, so at high resolutions (e.g. 3440x1440) they shrink relative to the larger-rendered units (upstream fbraz3#108/TheSuperHackers#867/TheSuperHackers#1607). Derive a modest UI scale factor from the display height vs a configurable baseline, clamped, and apply it to the health-box width/height and the veterancy readout font. New GlobalData/INI keys (GeneralsMD only, z_generals): UIFloatingScaleReferenceHeight (default 600) - baseline vertical resolution UIFloatingScaleMax (default 2.5) - clamp on the scale factor Set the reference height <= 0 to disable scaling. scale = clamp(displayHeight / refHeight, 1.0, max); never shrinks below authored size. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
This one i can continue and finish off pretty quickly, needs a rebase and a quick update based on the AI feedback. |
…ns relative to defaults
a482938 to
059e866
Compare
059e866 to
59ece0e
Compare
|
fixed bots feedback |
3 participants
This PR implements raw resolution and aspect ratio scaling for the unit health bar and other info icons.
This PR also adds functions to the display for calculating the display width and height relative to the default resolutions. And a function to calculate the diference in the current aspect ratio from the default.
Zoom based scaling to keep unit info scaled relative to units will be looked at in another PR.
There is also a small fix for the veterancy icon positioning as this was not implemented properly in the original code and broke when the health bar is scaled properly.
The only thing not scaled in this at the moment is the bombed icons, these will be dealt with in another PR.
This is due to icon placement changes being required so the icon is placed on the target instead of at the feet of the unit placing the bomb.