Godot: Godot scales the screen in Windows when fonts and applications size is greater than 100%

[miskatonicstudio]

Godot version:

3.0.6

OS/device including version:

Pop!_OS 17.10 (Artful Aardvark)

Issue description:

After releasing a game I've received a lot of feedback from Windows users that the buttons in main menu are not visible, making it impossible to even start the game. It turned out that the problem occurs if "fonts and applications size" (I'm not sure what is the exact name) setting in Windows is set to more than 100%. The setting doesn't seem to affect the screenshots. Below is a screenshot from Steam took with F12 key and a photo of the screen. The setting in this case was 125%, but if it is set to 150% the buttons are not shown at all.

Screenshot:

Photo:

This affects other 2D screens to, not only the main menu. If there is a flag in Godot that can fix that, I'd really like to know :)

Steps to reproduce:

Minimal reproduction project:

[volzhs]

what about setting Strech > Mode to 2d and Aspect to keep_height or expand at Project settings > Display > Window?

[miskatonicstudio]

I'll try that, thank you, but how will it affect other 2D game elements? The current Stretch -> Mode setting is disabled, because I wanted to keep the 2D elements in their original size (scaling up or down looks ugly). If I set it to 2D, that will probably scale them with the rest of the screen?

[volzhs]

yes it will.
but how can you cover up all the different monitor resolution and aspect ratio without scaling?

[miskatonicstudio]

A good solution might be an option in Godot to disable scaling when this "fonts and applications size" feature in Windows is enabled. Then a Godot program would keep the resolution of the screen (if in fullscreen) or the project size setting (when in window mode), while 2D elements would keep their original size. Another words: an option to ignore Windows scaling and use the monitor size and Godot settings.

[miskatonicstudio]

Today I tried to use Mode -> 2d and Aspect -> keep_height. Unfortunately, the problem still occurs. Then I tried all the other combinations of Mode and Aspect and none of them works. The only relatively good effect was when I set Shrink to 0.8 (Size of text, apps, and other items in Windows was set to 125%) and set the layout to center (instead of full screen). But then there was a problem with actual cursor area vs screen area (cursor couldn't reach all the places and hovering the buttons was not correctly detected). Besides, to use Shrink properly I'd have to read the current value of Size of text, apps, and other items automatically and then set Shrink to 1/value.

I've already received some feedback (and several negative reviews) regarding the users not being able to start the game because they don't see the buttons in the main menu. It is a serious problem for me, and telling users to "just set the size to 100%" is not a proper solution (they have the right to expect the game to just work). I think the best solution would be for Godot to have an option to ignore Windows settings and just use the whole screen with current resolution. Is such a thing possible to implement?

[Calinou]

Try enabling Allow Hidpi in the project settings (it's disabled by default, but I really think it should be enabled by default by now), which will make Godot start as a DPI-aware process. This can also be done on any executable by right-clicking it, choosing Properties -> Compatibility then setting the window scaling mode to Application.

[miskatonicstudio]

@Calinou Allow Hidpi doesn't work, however, setting the scaling mode to Application does! As soon as I figure out how to edit .exe file properties on Linux, I'll be able to automatically ship a fixed Windows executable to Steam. This workaround works for me, since it doesn't require users to change anything in their configuration (developers will to it for them, just like it should be). Thank you very much for your help!

[miskatonicstudio]

Turned out that the settings is kept in Windows registry, not in the .exe file itself. Nothing a simple .bat script couldn't fix ;)

[Calinou]

The proper solution would be to mark the processes created by the Windows executables as DPI-aware, which requires a small code change. It was done a while ago, but it was reverted because it made Godot no longer work with Intel Sandy Bridge graphics.

Edit: I noticed this should be the case when Allow Hidpi is enabled (https://github.com/godotengine/godot/commit/eb0f9651b3bb12b79db4ee4f8862a3be16a11ea5), but it doesn't seem to be working on your end for some reason.

[fodinabor]

Did you log off from your user after changing the DPI value?
After I did so and tested Allow HighDPI is sufficient. The label in the screenshots is layouted as Center Left.
Without Allow HighDPI:

With:

Setting Allow HighDPI uses the SHC_PROCESS_SYSTEM_DPI_AWARE and not SHC_PROCESS_PER_MONITOR_DPI_AWARE (only supported from win 8.1). As of this table, this leads to streching the UI by windows, if you changed the DPI value in one login session.
So your users won't have this issue, as they probably don't change their DPI value in the same session.. (and you are warned by windows, that this could / will happen)

[akien-mga]

So setting "Allow HiDPI" on by default might be an acceptable solution for now?

[Calinou]

@akien-mga I think it should be enabled by default, as Windows' compatibility scaling doesn't behave well with fullscreen applications.

[miskatonicstudio]

Instead of running the game directly I'm using this .bat file:

REG ADD "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /V "%CD%\Intrepid.exe" /T REG_SZ /D ~HIGHDPIAWARE /F
Intrepid.exe

It works fine, but I think in the future Godot should not require such workarounds. There should be a working option in Project Settings that would disable Windows scaling mode.

[fodinabor]

@miskatonicstudio could you please confirm whether your game runs fine with Godot's "Allow HiDPI" after a restart / relogin?
(don't forget to reset the registry key if you want to run the same exe)
If that works, it would mean that there is no workaround needed atm already...

[miskatonicstudio]

@fodinabor just to confirm, you want me to:

• set "Allow HiDPI" in Godot
• build the application
• restart Windows
• run the .exe file (not the .bat file)
  is that correct?

I can try to confirm that later, but currently I don't have Windows installed (I'm using other people's computers for testing :smile: ). However, Intrepid is now in public domain, so, if that's not a problem, you could try to check that solution:
https://github.com/miskatonicstudio/intrepid
You will have to add test fonts and sounds (I will provide them later, but I don't have the time now to review all the licenses), apart from that the project should be good to go.

[fodinabor]

most important is, that you do:

1. set DPI in windows settings, before
2. restart Windows (logging off the user and on again is sufficient, btw.)
3. run the .exe file (not the .bat file)

It's not important at which point you build the game.

[fodinabor]

@miskatonicstudio any update whether or not "Allow HiDPI" is sufficient?

[miskatonicstudio]

@fodinabor set DPI in Windows settings => that is not really a solution, since this includes Windows settings, which, from what I've gathered by far, are kept in Windows registry, not as part of the executable itself. Therefore, when a game is distributed via Steam, users would have to manually enter the Steam directory and configure the executable properly. That is way more than I can demand from people who just want to play the game.

The script does the job for now, but from what I've checked "Allow HiDPI" option in Godot didn't work, and it should (somehow allowing Godot games to ignore Windows settings).

[fodinabor]

@miskatonicstudio The set DPI in Windows settings was only meant for your tests.

The thing is: if I have let's say 125% activated on my PC as standard, everything works flawlessly with Allow HighDPI.
But if I have 100% and change it to 125% for testing on my machine, but don't log off after changing that, Windows hasn't updated the system settings, so Godot (and most other applications) thinks it is still 100%.

So all I want you to confirm is, that Allow HighDPI is correctly doing the job to scale your game, when used on a PC where HighDPI is configured by default.
And I wanted to say that, to simulate this behavior, you have to set the DPI setting, log off, log on, and then test the game with configured Allow HighDPI

[reduz]

This is a bug and it is fixed in godot 3.1 by the way, I would close.

[reduz]

Please try with Godot 3.1 and let me know if it still breaks, but I am confident it should not.

[miskatonicstudio]

@fodinabor @reduz Thanks for your instructions, but for now I am unable to test the solution. I don't have a working development environment on Windows (I can barely run the game on that OS), and therefore at the moment I don't have the time to check if 3.1 with proper settings will work. I hope to get back to this once other, more urgent company matters are taken care of. If you are not OK with waiting, you can close this issue, for Intrepid I've used a .bat script that works very well as a workaround, so I'd say the problem doesn't bother me anymore.

If, however, you think that a solution for 3.1 should be properly confirmed, give me some more time. Also, if you know anyone with a Windows development environment, you can ask them to download the source files and test the solution:
https://github.com/miskatonicstudio/intrepid

[CurlyBraceTT]

On version 3.1 - turning on Allow Hidpi solves the issue - game is no longer scales with sizes greater than 100%

[akien-mga]

Since all testers seem to confirm that Allow Hidpi solves the issue, we should probably just turn it on by default.

[BenMcLean]

The Godot editor itself is also affected by this issue. The bottom parts of controls in the editor can get cut off on Windows on high DPI settings. A workaround is to set "Override high DPI scaling behavior. Scaling performed by: Application" under "Change high DPI settings" in the properties for the executable for the editor. However, this workaround should not be necessary because all Windows applications are expected to be DPI aware as discussed in this article from Microsoft. This issue especially affects people with low vision.

[Calinou]

@BenMcLean The editor is always set to be DPI-aware. Maybe there's a bug in the implementation?

[BenMcLean]

I have noticed that I sometimes still get this cutoff happening even with that option set so I guess it isn't Windows DPI related after all. Don't know why this happens to me.

[fossegutten]

Scaling Windows by non integer values (175%, 250% etc.) caused unwanted anti-aliasing in my pixel art games, because of this.
Allow Hidpi fixed problems for me!