HighDPI UI behavouir

[DarkMicro]

What always bothered me about SoH was this when playing on my 4K Monitor:

The UI needs to be set on X-Large and the Font looks not that great. Also you can barely see the litte ship in the left corner which looks very ood but thats a problem of Shipwright. (But can be solved in the same way)

ImGui provides a CurrentDpiScale value which holds the perfect scale to compensate the dpi difference.

float scaleCurrent = 1.f;             // Needs to be 1.0 at start
float scaleNew, scaleDiff;

scaleNew = GImGui->CurrentDpiScale;   // Get the CurrentDpiScale
scaleDiff = scaleNew / scaleCurrent;  // Get the difference between the last frame and the current Frame 
scaleCurrent = scaleNew;              // Store the new scale

// And apply the scaleDiff to ImGui
ImGui::GetStyle().ScaleAllSizes(scaleDiff);
ImFont *font = ImGui::GetFont();
font->Scale *= scaleDiff;

2160p	1080p

With these changes the UI goes to a reasonable size no matter which resolution is used. Even if you move the window to a monitor with a different resolution the UI automatically applys the new DPI scale.

I also implemented OpenSans-Semibold as default Font to make it look nice and crisp at High DPI. But feel free to get a better font in the future. I only took that because it was convenient.

I only tested this on Windows 11 and Ubuntu 23.03 so maybe it breaks on other platforms.

That should increase the user experience. 🤓

[Malkierian]

I take it, then, this applies scaling automatically, making the scaling option dropdown redundant? If the default size plus the scaling coefficient looks that readable on any screen resolution, I see no reason to keep the dropdown around. Not sure if that needs to be done here or not, though.

I'm curious, though, when using the dropdown, going from .75 to 1 or 2 and back multiple times would gradually desync the base value, such that 1 could look significantly bigger than it should or does when you first boot up SoH. Does that happen with this? Say, if you were going from 4k to something between that and 1080p and back again.

[DarkMicro]

No i didn't experience anything like that. The only thing is if going to a smaller scale in the dropdown and drag the window to a different resolution the row paddings are getting messed up:

But i think this menu is useless now like you said. Large would be too big to use.
The base menu size should be increased by ~25% imo like this:

That would be perfect to use.

[Kenix3]

First thing I've noticed:
What are the licenses in the new fonts being included?

Further our pattern is to load data from the archive instead of include it with the executable. The font C file breaks that.

[DarkMicro]

That would be SIL OPEN FONT LICENSE Version 1.1 Source: https://github.com/googlefonts/opensans/tree/main?tab=License-1-ov-file

Didn't know that would be a problem since we allready have that font c file which also loads FontAwsome.

[Malkierian]

The problem with gui element sizing and padding is known, and a side effect of them not having been made with scaling in mind.

Btw, how does this mesh with Windows DPI scaling? It looks like the difference you showed between 1080 and 4k was the same proportion. If you increase Windows DPI setting, does it still look the same size on 4k as it does at 100% for 4k?

[DarkMicro]

I have set the scale of my two monitors to show the OS windows at the same size. The 4K at 175% and the HD at 100%. It seems like ImGui grabs that setting for the CurrentDpiScale value. If i change the scale in the monitor settings and restart soh it changes the size. So that works as it should be.

[Kenix3]

That would be SIL OPEN FONT LICENSE Version 1.1 Source: https://github.com/googlefonts/opensans/tree/main?tab=License-1-ov-file

Didn't know that would be a problem since we allready have that font c file which also loads FontAwsome.

Ah my mistake. I'm not saying it's a problem, just asking questions since it came to my attention just now. Double checking, you know.

I think we still probably want to load fonts externally instead of building them in, though

[DarkMicro]

Ok i get that. I think you want to add it to soh.otr right? I removed the font change so it can be done in soh instead.

[Kenix3]

Thankyou for addressing the feedback. Will leave this open for others to take a look for a few days.

[DarkMicro]

I rewoked the scaling like suggested by @briaguya-ai . Now we get the display DPI ourself and calculate the scale at specific window events. In DirectX i use WM_DPICHANGED like suggested and in SDL i use SDL_WINDOWEVENT_DISPLAY_CHANGED.
To scale the GUI at application start, i set a flag right after i called ImGui::NewFrame(). ImGui needs to be fully initialized to accept scales without an error. Because i use a flag to run the scaling once i can't use wParam of WM_DPICHANGED if you're wondering why i use GetDpiForWindow for Windows.

I also implemented a public function to provide the current scale to the game: LUS::Gui::GetCurrentDpiScale()
This should be usefull to scale textures like the ship icon.

I tested it on Windows 11 and Ubuntu 23.10
The new code has the same functionality as before.

[Spodi]

GetDpiForWindow is Win 10 and up only. Definitely breaks compatibility with Win 8.1, wich the last release of SoH still worked with (another user on Discord confirmed it working).
You can probably use GetDpiScaleForMonitor instead like this:

if (event.Win32.Msg == WM_DPICHANGED || mDpiInit) {
    HMONITOR monitor = MonitorFromWindow(static_cast<HWND>(event.Win32.Handle), MONITOR_DEFAULTTONEAREST);
    dpi = (float)GetDpiScaleForMonito(monitor);
}

EDIT: Apparently you need to link more dependencies with the Windows default. Urg

[Spodi]

There also is ImGui's ImGui_ImplWin32_GetDpiScaleForMonitor for Windows. This is already a scale however.

[DarkMicro]

Yes you're right. I didn't see that.

What i could do is this:

if (event.Win32.Msg == WM_DPICHANGED || mDpiInit) {
    HMONITOR monitor = MonitorFromWindow(static_cast<HWND>(event.Win32.Handle), MONITOR_DEFAULTTONEAREST);
    dpi = (float)ImGui_ImplWin32_GetDpiScaleForMonitor(monitor) * USER_DEFAULT_SCREEN_DPI;
}

ImGui_ImplWin32_GetDpiScaleForMonitor gives me the dvided by 96 scale value.
Better would be to link aginst Shcore.lib and just use GetDpiForMonitor instead.

[DarkMicro]

A better idea is that we just get the scale in both windows events and save the extra step. I updated the code.

[Kenix3]

See #502. This had to be taken out.