|
|
settings_Wrong.JPG (123,974 bytes) |
|
|
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. |
|
|
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. |
|
|
10-4. That is indeed a nightmare of a scenario, to be sure. Sorry you're having to go through all that. :/ |
|
|
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. |
|
|
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. |
- Anonymous
