Screen Resolution Settings

Development Rendering
1

HI all,

I’m trying to get my resolution settings to work correctly. They do for the most part, but if I set the game to be in Windowed mode and change the resolution, instead of having lower res change the screen size it simply goes into some sort of a windowed mode.

I should note, I’m trying to avoid using console commands to setup the menu.
but r.setres 800x600f or 800x600w produce the same result.

Using 4.23.1

Can’t seem to figure this out.

Apparently this is a “me” problem too. something I did with the project settings or at some stage of dev. the f or w options work fine in a new sample project, and not at all in my own…

removing all the .ini files seems to have resolved it.

2

Hi MostHost LA,

I’m also adding a window / fullscreen option to my game right now, things I mention below may not solve your problem directly (it might even have nothing to do with your issue), however, it might serve as a checklist to see if you made the same mistake I made earlier.

  1. Test resolution and window mode in packaged build (not in PIE or standalone)

The important thing I found out after watching this short tutorial video: WTF Is? Fullscreen Mode in Unreal Engine 4 ( UE4 ) - YouTube

is that (around 02:57 in the video), the resolution and window mode console commands or even C++ UGameUserSettings->SetFullscreenMode() may not work properly under either PIE or Standalone.

I also experience the same thing myself, so I always test these options under packaged build.

  1. It’s better to use a single resolution and change the percentage instead of multiple resolutions

This may be a bug or something I did wrong, however, when I apply various 16:9 resolutions to my game with console commands:

“r.setres 640x360”
“r.setres 960x540”
“r.setres 1280x720”
'r.setres 1440x810"
“r.setres 1920x1080”

for some reason, only 1280x720 and 1920x1080 give me the correct result, the other 16:9 options result in weird UI offset. So, instead of applying multiple resolutions I use:

“r.setres 1280x720,r.ScreenPercentage 50” (640x360)
“r.setres 1280x720,r.ScreenPercentage 75” (960x540)
“r.setres 1280x720,r.ScreenPercentage 100” (1280x720)
“r.setres 1920x1080,r.ScreenPercentage 75” (1440x810)
“r.setres 1920x1080,r.ScreenPercentage 100” (1920x1080)

that way, all the resolutions are applied correctly and UI offsets properly.

  1. The cursor is “bounded” in a previous (smaller) resolution

This happens to me when I change from window mode to fullscreen mode with higher resolution, the cursor did not recognize the resolution has changed and was unable to move beyond the range within the previous resolution.

I need to call

PController->SetInputMode(FInputModeUIOnly());

after the resolution change to unlock the cursor. (use alt + tab to manually re-focus the packaged application also fix this issue, but it’s quite annoying for players every time they want to set a different screen mode)

That’s all the weird stuff I encounter when I try to add window / fullscreen mode to my game.

Hope this helps~

3

So, my initial issue was related to forcing DX12 as the RHI for windows.
Apparently with DX12 the full screen is never fullscreen. If I change the option in settings I get the same behaviour on a blank project.

The secondary issue is that setting fullscreen often crashes the engine. Apparently there is a similar issue that is marked as fixed for the next engine update (Setting mode to full screen when the mode is already fullscreen). Seems to me this particular part of the engine is experiencing difficulties and making packaging for the jam hard fought if not just pointless.

Fortunately, the removal of the DX12 option is enough to get even the test machine to launch at the correct fullscreen res. The issues only happen if someone goes changing graphic settings.

I toyed with your idea, its viable but I just dont like it.
It works, but it’s not exactly the same.

Btw, when you use r.SetRes you should include the f or the w at the end for windowed or fullscreen. Not sure that will make a difference for how stuff renders, but ita worth a shot.

Also, re testing in the Packaged version.
Yes, I usually have been doing that, and no, almost none of the settings work in PIE.
I just wish one could package a specific scene for shipping without changing half the project or altering settings… Getting to the part where one can test is getting annoying.

Anyway, thanks for the tips.

TL:DR
Switch RHI for windows to DX11 or Auto and the screen will function as it is supposed to.
Force DX12 and the full screen will always act as windowed (no idea why).

4

Hey~

Yeah, I append the “f” and “w” in code afterwards, I also discovered there’s a “wf” suffix for windowed fullscreen option XD

Anyways, glad to hear you solve the issue!

5

I know there’s more to it than this, but it probably has something to do with how the screen resolution matches or doesn’t match the display screen size(s)…meaning the screen size of the monitor and the display size set in Windows. It would seem to make sense with the various resolutions other than 1280 x 720 and 1920 x 1080 not working correctly. It would also seem to make sense in the described case of changing resolution from default to a different one in-game. This is an issue involved in web design, as the settings for resolution need to align with the default or non-default preset ratio (4:3 or 16:9, or another). It was an issue with movies, whether widescreen or full screen, or letterbox, or the less common ones. Certain tv screens do not display every ratio with the same exactitude of keeping all visuals within the screen. Instead, they get stretched, squeezed, etc., due to a mismatch between screen size and built-in display resolution. The tv I watch on extends some text a little bit beyond the side edges if I change to ‘More Readable’ mode. And it’s a cable box from Comcast that is built to display HD content, while the tv is an older SD. It’s kinda similar to changing the size of a photo / image in an editing application, but not changing the size of the working area of the project. The application may either stretch or squeeze the image to fit the working area, or it won’t and the image / photo gets skewed beyond or within the boundaries.

6

UE does the adjustments internally if you use the correct settings.
The end result is the actual resolution pushed to the user matches per pixel what was requested. Regardless of monitor actual size or display proclivities.

What the monitor then does or does not do with that data is usually handled by the GFX or monitor itself.

The UI/widgets scale differently with their own internal way of handling that to provide accurate print.

Either way, the end monitor interaction that’s up to the GFX is why having a proper Confirm screen is important when changing resolutions. If you just confirm the values for the user without any checking you end up getting errors.

Ofc, you can bypass that by pulling the res off the suggested list and not allowing custom ones. (But a confirm/apply is still a better way to go).