Fix High DPI displays

[eddebaby]

The exe now includes a manifest, which declares that KeeperFX is dpiAware (Win7 and earlier) and has multi-monitor dpiAwareness (Win8.1 and later).

The Application now renders "as if DPI scaling is set to 100%". It does not yet scale with DPI, but the Window and Rendering are no longer "too big" with a higher DPI. Works across monitors with different DPI scaling (windowed mode, as you have to move the window).

If you change DPI scale percentage whilst the game is running, then the window height gets messed up. This does not appear to affect fullscreen mode. [this should be resolved at some point, but it is a fringe case]

The manifest file requires the trustInfo section, to work with UAC, if it is missing, or if this file is invalid in some other way, the dpiAwareness settings will not be honoured.

The formatting of this manifest file, and the way to add it as a resource, were pieced together from the following sources:

• [getting manifest into the exe] - https://stackoverflow.com/questions/29003832/how-to-add-assembly-manifest-file-to-exe-file-created-with-netbeans-ide-c-min
• [formatting the manifest file] - https://stackoverflow.com/questions/13228185/how-to-configure-an-app-to-run-correctly-on-a-machine-with-a-high-dpi-setting-e/13228495#13228495
• [correct dpiAwareness settings] - https://stackoverflow.com/questions/23551112/how-can-i-set-the-dpiaware-property-in-a-windows-application-manifest-to-per-mo

Moving forward, this is a great resource for handling DPI with SDL:

• https://nlguillemot.wordpress.com/2016/12/11/high-dpi-rendering/

[Loobinex]

Works great for me in Win10.

[eddebaby]

Does this happen for you too Loobinex: "If you change DPI scale percentage whilst the game is running, then the window height gets messed up. This does not appear to affect fullscreen mode. "?

[Loobinex]

I see no difference between changing the setting while the game is running, or doing it before starting the game. However, if I set the window to 1600x1000w32 on my 1920x1080 monitor with 150% scaling, it does not all fit.

[eddebaby]

Just to make sure: to trigger the issue I describe, run in windows mode, whilst the game is running - change DPI scale amount, and then move the game window around. It might be easier to test with a small 640x480 window. The window grows a bit, and if you continue to move the window: it will decrease in height until it is just the title bar.

For the other issue, I think it falls in to the "Window Feature" category. Before I explain the details of that, I need to run some quick tests on my end, to make sure my assumptions are not faulty, otherwise there would be a wall of text that could be completely wrong. Then I'll reply again. Either way, we could potentially handle/fix it in the code, or at worst warn the user in the log file.

[Loobinex]

Yes, if I run the game with -altinput and change dpi settings during gameplay and then start to move the window around it bugs out a bit. Pressing alt+R fixes it again.

This is a non-issue. Nobody changes DPI settings during gameplay.

[eddebaby]

When I test with 150%, 1920x1080 monitor, 1600x1000 window: the bottom of the window is slightly cut off, but it seems to just be behind the task bar. If I hide the task bar, the window fits on screen. Is this your experience?

[Loobinex]

Yes, even at 175% that's the behavior.

[eddebaby]

So a window is never bigger than the screen, but can become hidden behind the task bar?

As far as I am aware, this is "Windows behaviour", the taskbar gets in the way with >100% DPI, I haven't massive experience with it but I have seen it in the past with other applications. I suspect that the task bar might get in the way sometimes if you use a 1920x1080 window too. Maybe there is a way to keep the window on top of the taskbar, I'll google for solutions.

[Loobinex]

I'd just keep it like this. All we need is somebody to test win7 and we're good to go.

[eddebaby]

OK that sounds good to me. It does seem to be a general issue (even with MS applications), and the user can hide the task bar, if their setup exposes this issue. I think the only way to solve it would be to detect that the issue would arise (SDL_GetDisplayUsableBounds is too small to fit the window), and create a smaller window instead, which isn't ideal (the user's requested window size is not fully honoured). I could not find any mention of SDL applications that force themselves to render "in front" of the task bar, but surely this isn't advisable either.

[eddebaby]

Windows 7 - 1920x1080 monitor - 150% DPI scaling:

• The same results as reported for Windows 10, including with the 1600x1000 window (it is obscured by the taskbar).
• Windows 7 results were like this before, without this pull request. (I'm not sure I stated this before in this thread)
• The fringe case cannot be triggered, as the user must log out to change the DPI scaling amount.