dosbox-staging should be made DPI-aware

[warpdesign]

Is your feature request related to a problem? Please describe. dosbox-staging doesn't seem to take into account HDPI screens/scale level.

This is how dosbox appears on my Surface Book (3000x2000 screen, desktop scaling set to 200% in Windows settings (that's the default)):

The terminal window is correct but dosbox's window is way too small.

Describe the solution you'd like dosbox staging should follow the Windows'display scaling value and scale the window accordingly.

Describe alternatives you've considered I guess changing the resolution in dosbox-staging config file could mitigate the problem. But then, moving the window on a monitor with a different scaling (eg. HD screen with 100% scaling) would result in a too big window.

Additional context This is what my display settings panel look like (again, it's Windows'default setting, I never touched it):

[dreamer]

@warpdesign I will go a step further and call it a bug and not a feature request :)

The reason why this is happening is because we never want OS-level pixel-doubling to be involved - it's another layer of complication to our internal scaling and interferes with mouse emulation. On Windows windowresolution = default falls back to original, which is not helpful at all.

The reason why this is a problem for Windows users and not such a big deal for Linux users is because on Linux we default to resizable window (on Windows it's an opt-in feature).

So for now, you can try one of these three workarounds:

• Try windowresolution = resizable (during resizing the window is black and emulation stops - that's a known problem, don't bother reporting it, please)
• Try custom resolution of your choice - e.g. windowresolution = 1600x1200 should work very well for your screen.
• Keep windowresolution = default and try using glshader = crt-fakelottes-flat - it will trigger adaptive window size algorithm that is enabled only for specific shaders ATM

Aside of available workarounds, we need to adjust the behaviour of windowresolution = default to work better on high-resolution displays.

Note for myself: this is related to #716, #274,

[GranMinigun]

Keeping this open for possible future per-monitor DPI scaling support (see https://github.com/libsdl-org/SDL/pull/5778).

[GranMinigun]

So. Some good and bad news. gm/windows-hidpi-1 branch seems to mostly work on a single-monitor setup. But I only tested texture output, and there was a problem: switching scaling setting down (e.g. from 125% to 100%) freezes output in windowed mode. This is most likely because of the output mode sorta-kinda not supporting window resize. That can be fixed.

If someone can, please do test dual-head setups and OpenGL output, with and without shaders, including pixel-perfect mode. You can follow a checklist from here:

1. Moving application windows back and forth between displays of different DPI values
2. Starting your application on displays of different DPI values
3. Changing the scale factor for your monitor while the application is running
4. Changing the display that you use as the primary display, signing out of Windows, then re-testing your application after signing back in. This is particularly useful in finding code that uses hard-coded sizes/dimensions.