Discrepancy between element dimensions in pixels on figma designs and dimensions in game units

Type

Cosmetic

Bug description

I’ve mentioned this several times over, but opening as an issue at @peppy’s request.

To implement screen scaling, the game wraps all its content in a DrawSizePreservingFillContainer:

https://github.com/ppy/osu/blob/7d338fb4be89e1de7c9195f3ab11b17e9aa83a70/osu.Game/OsuGameBase.cs#L321-L332

By default, DrawSizePreservingFillContainer.TargetDrawSize is 1024x768, which is a 4:3 ratio.

For desktop intents and purposes, it is not likely that the screen is going to be any “narrower” wrt aspect ratio than that (typical aspect ratios are 4:3 and 16:9, rarely 21:9 or wider), which means that most of the time the container is going to size its children relative to a full height of 768px. For instance, that yields a 1366x768 resolution at 16:9. Please see screenshot below as corroboration of this:

However, this also implies that anything that is a child of the scaling container is no longer using real pixels to scale, but faux-“pixels” relative to 768px height. This means, that if figma designs that specify sizes in pixels are taken at face value and values are copied over verbatim, on typical resolutions the end result is going to be 1080/768 = 1.4x larger than they might have been (were?) intended to be at design time. Please refer to screenshot below as corroboration of this:

This means that decreasing all figma sizes by a factor of 1.4x should yield in a pixel-for-pixel match. Unfortunately there is a complication for this, namely https://github.com/ppy/osu-framework/issues/3271 - the full paper trail is in that issue, but the TL;DR is that as it turns out, framework font sizes in pixels are too large relative to CSS pixel font sizes due to typography foibles, which means that fonts are partially exempt from this downscale operation.

I can see two immediate not-great resolutions:

• What I’ve been doing since the start of the mod overlay work (and it’s been pretty much only me thus far, at least when it comes to stuff that has actually been merged) is manually downsizing every single measurement by hand by a factor of 1.4x, with the font exemption.
• The alternative would be to downscale UI globally by using the UI scale slider, so that new 1x is where current 0.71x is (0.71=1/1.4). I’m mentioning this as an option because it was brought up in discord, but this also means that all of the other stuff that looked “fine” at eye value will become potentially too tiny to use after said adjustment.

I don’t claim to know what the answer is. It’s all a bit of a drag.

CC’ing potentially directly interested parties: @jai-x, @GSculerlor, @frenzibyte, @arflyte (that last one is mostly just for awareness, I don’t expect this to be addressed at design level at all)

Screenshots or videos

added screenshots in description above

Version

n/a

Logs

n/a

[bdach]

Does this look close to what you’d expect to see? https://github.com/ppy/osu/compare/master...bdach:ui-scale-to-design-size?expand=1

[frenzibyte]

I’m wondering if we can fix that in OsuFont (manually specifying the ratios to align them to expectations) until we have a proper framework solution.

That will require updating the font size of all OsuSpriteTexts we declared across the entire game, or creating a whole font family altogether that has this specific ratio in mind.

But I already have a simplified framework solution which I’ll look into PR’ing in just a bit. Short of a boolean in FontUsage which would decide whether the font size measurement should be in absolute pixels (as we currently have it), or CSS-style font size (how we should have it).