View Issue Details

IDProjectCategoryLast Update
0019275AI War 2Bug - OtherFeb 17, 2018 1:20 pm
ReporterChris_McElligottPark Assigned Tokeith.lamothe  
Status resolvedResolutionfixed 
Product Version0.600 Tutorial Engine 
Fixed in Version0.707 
Summary0019275: GUI Scaling Issues still remain.
DescriptionHey Keith,

So I figured I'd make this a bug report so others can comment on it if need be. Basically right now the way the GUI scaling is working is... only sort of working. Mainly because unity isn't properly scaling things like the text inside a textbox when you scaling the textbox to a different value. Unity just isn't built around the premise of people rescaling their entire GUI piece-by-piece like we are.

I think that one of the solutions to this is basically their logic for scaling canvases, and having the canvases have a "constant size" for all the elements within them. Right now each canvas is basically a window, and I think it's a safe thing to say that all of the pieces within a canvas should always remain the same size relative to one another. It's the canvas/window itself which is going to actually get larger or smaller and move around the game screen.

If someone chooses a smaller GUI scale in the settings, then all of the planet-view and galaxy-view canvases would get smaller than normal, and thus their internal stuff gets smaller as well. And if a screen is larger or smaller, the canvases are larger or smaller, too. But then for all the other screens in the game, basically those are resolution-agnostic in a lot of ways... I think? I mean, I guess they should be?

I don't know -- right now when I'm looking at, for instance, the settings menu at 1869x1088 in the editor, it looks correct in terms of the things that are shown in the textboxes are all legible and look correct. But running the same thing at 968x610, it's completely destroyed, more or less. I've attached screenshots of the two items in question.
TagsNo tags attached.

Activities

Chris_McElligottPark

Nov 1, 2017 12:21 pm

administrator  

settings_Correct.JPG (282,693 bytes)
settings_Wrong.JPG (123,974 bytes)   
settings_Wrong.JPG (123,974 bytes)   

Chris_McElligottPark

Nov 1, 2017 12:41 pm

administrator   ~0046549

It strikes me that basically there are two wildly different cases for GUI scaling:

1. The HUD, which is there all the time in some fashion during gameplay. Be that the galaxy map or the planet view. This is comprised of basically images, buttons, and text, and not much else. The scaling logic on this can be kind of whatever we want it to be, as custom as we need, because unusual GUI controls from unity, things like textboxes or scroll lists or whatever, aren't going to factor into this at all. They aren't on these parts of the GUI. This is also the really performance-intensive part of the GUI, it's worth noting. And the part that people care about doing custom scaling on.

2. The menus. This stuff frankly doesn't need custom user-based scaling in my opinion, as if it shows up too large that's not a crisis. The one exception is arguably the campaign startup screen. The performance of these bits isn't all that critical, since their data doesn't change every frame and the vast majority of the time the game is running these are not even visible. I include in that even things like popups during game for something like saving the game or changing your controls or renaming a planet or whatever.

So, following that line of thinking...

Perhaps with case 1, we pretty much stick to what you're already doing. It works! It almost completely works, anyhow, with a few nits here and there.

Perhaps with case 2, we take a more "traditional unity" approach to this. For example letting it scale the canvases itself, etc.

keith.lamothe

Nov 2, 2017 6:21 pm

administrator   ~0046565

The unity scaling just doesn't work in our case, even aside from the performance hits involved. Doesn't shrink in the right direction, things wind up looking weird, etc.

Our scaling happens at a very root level, can't scale some of the things and not other things. But it is true that the stuff that doesn't scale well (mostly just the text-inside-textboxes) is not on the screen at the same time as the HUD.

I tried having it ignore scaling entirely if the settings window is showing (the idea being "if a textbox is showing, just act like the scale setting is 1:1") but whenever I have it switch from scaling to not-scaling, the settings menu just completely disappears. That's probably something that can be found and fixed, but I tried for a couple hours today and need to just get the release out for now.

So I've put in some small corrections to text-in-textbox size when between 70% scale and 90% scale, and it seems to make it work ok. 60% or lower is still bad (because the TMP_Input's top and bottom padding appears to not scale nor be directly modifiable by us, so eventually the padding leaves no real space between), but I imagine those are used less often.

Chris_McElligottPark

Nov 2, 2017 7:41 pm

administrator   ~0046566

10-4. That is indeed a nightmare of a scenario, to be sure. Sorry you're having to go through all that. :/

Chris_McElligottPark

Jan 31, 2018 11:09 pm

administrator   ~0046802

At the moment the main things that seem affected are the text and smaller icons in the build menu buttons and the sidebar buttons. Those seem overly large when my screen is large, and unreadably tiny when my screen is small. The other elements like the tooltips feel like they are the same equivalent size in both situations, rather than being sized extra small or large.

keith.lamothe

Feb 17, 2018 1:20 pm

administrator   ~0046993

For 0.707:

* Fixed some discrepancies in how text was scaled (based on resolution and/or the ui-scale setting) compared to other UI elements.

In my tests it now looks pretty good, it can look very small when scaled down on a large resolution, but in those cases I think it was doing what it was told.

Issue History

Date Modified Username Field Change
Nov 1, 2017 12:21 pm Chris_McElligottPark New Issue
Nov 1, 2017 12:21 pm Chris_McElligottPark Status new => assigned
Nov 1, 2017 12:21 pm Chris_McElligottPark Assigned To => keith.lamothe
Nov 1, 2017 12:21 pm Chris_McElligottPark File Added: settings_Correct.JPG
Nov 1, 2017 12:21 pm Chris_McElligottPark File Added: settings_Wrong.JPG
Nov 1, 2017 12:41 pm Chris_McElligottPark Note Added: 0046549
Nov 2, 2017 6:21 pm keith.lamothe Note Added: 0046565
Nov 2, 2017 7:41 pm Chris_McElligottPark Note Added: 0046566
Jan 31, 2018 11:09 pm Chris_McElligottPark Note Added: 0046802
Feb 17, 2018 1:20 pm keith.lamothe Status assigned => resolved
Feb 17, 2018 1:20 pm keith.lamothe Resolution open => fixed
Feb 17, 2018 1:20 pm keith.lamothe Fixed in Version => 0.707
Feb 17, 2018 1:20 pm keith.lamothe Note Added: 0046993