Thing is, this is not a solution that will cover all the possible cases. I didn’t find this topic earlier, but I’d sure as hell bump it if I did.
The mapping that is there says: “give me the X resolution and I’ll apply the scale to both coordinates”. This does not work well. There are many resolutions that share the X size, but have different Y sizes, in which case the engine detects X and scales the Y and X not even checking what Y is.
1920x1080 and 1920x1200 (16:10) is one example. 1920x1080 and 2048x1080 is another case - Y is the same but X changes. The second one you could theoretically hack by spamming tons of points on the curve, but the first one is unavoidable.
If you really want people to stop using scaleboxes for such complex problems (which is what I’m doing all the time and have a pile of bug reports that just wait for me to have time to properly report them with examples) then maybe make the mapping like this:
“For given X resolution size scale X by XScale” && “For given Y resolution size scale Y by YScale”. This way you will cover all the possibilities. But this is also not ideal. Problem with this is that if you want to keep square a square for all resolutions, this will not work.
So, maybe “For given X:Y pair, scale by Z”. This would require a bit tweaking and wouldn’t look perfectly the same everywhere, but would preserve shape. Still, it would be impossible to ‘Fill’ the entire screen with the UI on each resolution, like in RTS games.
Thus the scaleboxes. They do manage to get the job done, although setting them up in a way that’s not bugged is painful and often impossible with more complex UI’s. If they’re so expensive then be it, but that’s the only way it works right now.
I don’t see a solution that will work with the DPI scale. Scaleboxes would cover that case if they worked well enough.