The bad news is that not all applications are really ready for this. Older protgrams, written before the high-rez era, show their window and UI contents as minuscule graphics, sometimes very difficult to work with when subjected to anything above 1920x1080. Modern OSs are taking care of this by providing user selectable higher screen DPI settings, that applications can make use of, in order to maintain their high quality of display, but also provide an interface that still remains legible and clear even at extremely high screen resolutions. For those interested, this is a quite nice intro: https://software.intel.com/en-us/blogs/ ... ing-issues.
When an application is run under high-DPI settings, Windows Vista and later will try to help it display better by rescaling its main window and interface by means of the so-called DPI Virtualization. However, rescaling the entire application like this, when the application was not designed with such rescaling in mind, can often lead to problems. Newer applications have ways of telling Windows not to do that, beacuse for example, the protgammers have already taken into account high-DPIness and are handling it within the application itself.
So, older apps written before high-DPI was a thing may have issues with DPI virtualization. Another class of applications very prone to issues is games. Those handle their window positions, resolutions and displays almost always internally and therefore tend to interfere with Windows DPI virtualization, activated when the OS sees that the game tries to run under a non-default DPI setting.
Oolite is one of those games hit by this. When you set the Windows scaling factor to anything above 120%, DPI Virtualization will kick in. Running Oolite 1.84 or earlier under such conditions will subject the game to undesired window rescaling. You will notice the following:
- Splash screen appears bigger than normal
- Game window appears much bigger than normal, part of it may render out of screen
- Going full screen has all sorts of weird side-effects, from inability to switch altogether, to unexpected window behaviour that may also depend on the gfx drivers, like failing to resize etc. Most importantly, when on multiple monitors, going fullscreen will cause the full screen window to cross-over to the other monitor. We've already had bug reports about this (see github issue 226), which we attributed to driver issues at that time. Now I'm 99% sure that DPI rescaling was involved.
This weird situation has now been fixed in trunk. Oolite now declares itself DPI-aware on startup, effectively telling the operating system "Look, I can handle my own display very nicely thankyouverymuch, now hands off my window, kthxbye". This solves the problem for 1.85 onwards. To fix 1.84 and earlier, there are two possible ways you can try, both very easy and simple:
1. Right-click on the oolite.exe file, select Properties and then, inside the Compatibility tab, check the box labeled "Disable Display Scaling On High DPI Settings", click OK and you're done. See image below for illustration.
2. Paste the below text into a text file and save it inside the oolite.app folder (where the oolite.exe also resides) with the filename
oolite.exe.manifest. When you launch the game again, DPI virtualization will be disabled and everything should look and act normal.
Code: Select all
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" > <asmv3:application> <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"> <dpiAware>true</dpiAware> </asmv3:windowsSettings> </asmv3:application> </assembly>
Edit: And this should hopefully work for both single and multi monitor cases:
Code: Select all
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" > <asmv3:application> <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"> <dpiAware>true/PM</dpiAware> </asmv3:windowsSettings> </asmv3:application> </assembly>