tutorials/rendering/multiple_resolutions

[giscus[bot]]

tutorials/rendering/multiple_resolutions

The problem of multiple resolutions: Developers often have trouble understanding how to best support multiple resolutions in their games. For desktop and console games, this is more or less straigh...

https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html

[troynall]

"However, what it does is not completely obvious; the engine will not attempt to switch the monitor to this resolution. Rather, think of this setting as the "design size", i.e. the size of the area that you work with in the editor. This setting corresponds directly to the size of the blue rectangle in the 2D editor."

The above text is very verbose. I think my version(the below text) is more concise.

"This setting defines the 'design size,' the workspace area you see in the editor, represented by the blue rectangle in the 2D editor. It does not switch the monitor resolution but establishes the dimensions for your design."

[mechalynx]

I don't see a problem with the length to be honest. Perhaps it can be seen as verbose as it takes longer to explain something than is strictly necessary but it fits the flow of the rest of the text.

I think it does a good job at making sure the user does not expect the resolution indicated to be the full-screen resolution and also hints that the default resolution is intended to match the editor preview. There is a possibility that the reader interprets the 'design size' explanation as something the editor will do by itself (e.g. the editor will set that resolution to the same one as the preview, when it is simply an initialized value) but having read it just now, I did not get that impression, though I already know how it works. So in that sense, it perhaps could be more clear that this is a helpful default, rather than some dynamically set value that corresponds to the preview resolution.

On the other hand, I feel the concise version you propose is more likely to confuse the user because it can be interpreted as defining the design size, which it doesn't. Reading it myself I think I'd have got the impression that changing this height and width would actually have an effect inside the editor, rather than during run-time (though the rest of the text would make it clear what it refers to).

I guess, if there is improvements to be made, it is that 'design size' should be described as a helpful default, without ambiguity, and that the resolution is, due to the 'Windowed' default, not going to switch the monitor to that resolution. This will work differently for 2D and 3D rendering but I feel that the rest of the text does an ok job explaining the difference because it mentions pixel alignments in 2D and that the scene will fit the resolution in 3D anyway.

[Real-EdgeLord]

from my personal testing ... godot at the moment does not have a real screen resolution settings that works as you would expect ... (I got all the down sides and non of the benefits) in 3D

on PC lowering the resolution in full screen is just point less as instead of actually lowering the resolution gain performance in the process ... you are down scaling the viewport resolution ... and if you upscale then you get nothing because it basically upscale the the viewport resolution again

this problem creeped up on me when i set up my cross platform (mobile and PC) viewport resolution to 1920x1080 and noticed a sharp drop on the mobile FPS ... this was expected and when i decided to drop the resolution using the settings i found out that I can't really do that to gain FPS ... not even on PC

I have tested multiple ways wrong and right read the docs (clearly) and looked at settings plugins and looked online a lot and these function are what I got across

get_window().set_size(Vector2i(960,540))
get_viewport().set_scaling_3d_scale(0.2)
DisplayServer.window_set_size(Vector2i(960,540))

var viewport: Window = get_tree().root
viewport.size = (Vector2(960,540))

no of which matched the performance of setting your view port to the default 1152x648 which was a higher resolution than what I was testing

coming from unreal i though the viewport setting was more of a guide (which is confirmed in this doc), and just like in unreal (and unity now that I think about it) changing your resolution on mobile is a bit of a No No (God knows why) ... and I would have been ok with that if I could see the real quality increase on PC ... and sadly changing the viewport scale before building won't work because it is what your UI scaling realize on (as it should)

if any one has a real solution to this please share it ... other wise i would have to down scale my game to run smoothly on mobile and drop the graphics finial graphics quality for PC along the way

Note: considering how fast Godot runs, how would one develop for PC only ... the quality lose because you set the viewprot to 1920x1080 when the game runs on 4k is significant, and the performance lose when running a 4k viewport on 1920x1080 is really big ... both of which (in the case of 3D) have no really reason !!??

[Real-EdgeLord]

sadly ... it is one of the function that I have tested ... and it did not match the performance of changing the viewprot in the project settings ... not even close

I will look into feature tags ... but I don't think it will help as I have no problem even switch the viewprot width and height manually before building ... the problem is that it breaks the UI for one or the other

testing the scaling_3d_scale ... with the viewport rez set to 1920x1080 the scale at 1 (not changed) gets me 480 to 540 FPS on pc
testing with scaling set to 0.5 (equivalent to 960x540) get me 540 fps avrg (from 480 up to 600)
testing with viewprot rez set to 960x540 in the project settings (full screen) ... from 840 to 960 Fps

the scene is 3 cubes with red material, an environment and a point light ... however I am using compatibility (not forward+ nor mobile)

[Real-EdgeLord]

this took a long time to get to again but ... I kinda found a good enough solution ... its downside is that it requires restarting the project, and going through hell making the UI of the entire game

I override the PC settings with features ... and when I need to change the resolution on pc I call

ProjectSettings.set_setting("display/window/size/viewport_height.pc",1280)
ProjectSettings.set_setting("display/window/size/viewport_width.pc",720)
ProjectSettings.save_custom("override.cfg")

then I restart the Game using

var base_path = OS.get_executable_path()
if OS.has_feature("windows"):
exe_path = '"%s"' % exe_path # Wrap in quotes for spaces in path
var args = []
OS.create_process(exe_path, args, false)
get_tree().quit()

I don't really like any of this but it gets the job done so I can't complain ... as for the UI well I have to write a script that gets the original viewport scale and change the position and scale for each item according to the ratio of change

Yup that is hell ... but I will do my best to make it one script that can fix all UI elements and try to figure out how to attach it to Nodes that already have scripts ... good luck me

[Calinou]

This does not actually perform modesetting on the PC's display. This only sets the viewport to run at a fixed resolution, something you can do without restarting the process by setting properties on the root Viewport at runtime (get_viewport() in any Node script).

PS: When comparing performance, it's recommended to compare milliseconds per frame rather than frames per second. This avoids skewing results at very high framerates where some differences may seem large, but are actually rather small in the grand scheme of things. The formula to calculate mspf is 1000.0/fps.

[Real-EdgeLord]

This still needs more looking into but I have gathered a bunch of notes ... and a 97% working solution

one of my biggest mistakes turns out that I had set
display/window/stretch/mode to viewport ... instead of canvas_items ...

setting it to canvas ... kept the correct scale for the UI at the design resolution ... however the Game was running at the screen resolution
( for most godot games that is perfect ... but not in my case for mobile),

in this mode the
get_window().set_content_scale_factor(1.5)

lets you resize the UI only (when I say UI i am talking about canvas items) ... and it does not effect the 3d resolution, this on mobile cause a problem as most mobile devices ( well first they crash and burn if you use the mobile render, which is not Godot fault had the same problem using unreal vulkan on mobile almost the same exact miserable performance (20 to 35 fps) on multiple modern budget devices) ...

this happens because most mobile devices are actual more than 1080p ... using compatibility rendering (OpenGL) i manage to get 50 to 40 FPS ... (fun fact almost the same FPS using unreal) ...

but considering the small screen size you can get away with less resolution (I had a hard time recognizing a meaningful difference in my testing) ... in any case I wanted to give the player control over the quality... you have a high end device you can keep the high rez ... you don't you can change it ...

this is where i got into trouble I found out that setting

display/window/stretch/mode to viewport
enforces the design resolution to be used ... with the performance benefit and then changing the scaling with
get_window().set_content_scale_factor(1.5)
or using
get_window().set_content_scale_size(Vector2(1920,1080))

changes the that actual resolution in both case you get the performance befit/cost. Catch is your UI runs wild

I went back to canvas_items and tested
get_viewport().set_scaling_3d_scale(0.666)

again based on your feedback ... As i knew you where right but i did not know how
and this time it worked really really well ... kinda ... enough

in my past testing (with viewprot preset) ... set_scaling_3d was more of a post process effect ... it had no significant effect on performance, this was the result of my perverse testing

but this is not really the end ... as when I drop the rez to 960 by 540 (exactly 0.5 of 1080) using both methods I noticed strange things
first using canvase and 3d_scale of 0.5 :

ignore the UI scaling and the models are stole for testing ... the characters look alright for 960x540 but they are a bit blurred, the frame time is about 1.28 (780 Fps) overall not that bad ... and i get to keep UI stable

but when I switch to viewport and then used set_content_scale_factor(2):

first note is the slight performance increase to an average of 1.19 ( 840 fps) but things are a bit pixelated ... sharper yes but still pixelated yet again we are rendering at 960x540 ...

the thing is in both case I had MSAA craned to 8x (as you should when you have 700 fps)... is it the reason for the blurriness, is it the reason for the overly sharp image in the second case ... it can't be both ... but it can be none

at this point I already have my solution ... which saves me from the hell of the custom scale scripts for every UI element, but their are two things bothering me, that slight increase in performance on PC is nothing but on mobile it is the difference between running at 70 fps (really good) or 90 FPS (the max refresh rate) at (1280,720) of a budget device, the the blurriness is not that great, plus we know that 3d_scaling is not really rendering at that scale ... it is in its settings SCALING_3D_MODE_BILINEAR ... that is why FSR a scaling model is another preset for 3d_scale to use (kinda same results)

as for scaling up to 8K on PC ... I honestly could not tell both of them did a great job and dipped the FPS to 100 for scaling+viewprot and to 300 canvas+3d_scale ... (from 660 at 1080)

in conclusion scaling+viewport I think gives you the real resolution ... but say good by to your UI
canvas+ 3d_scale keeps your UI and is good enough ... but is not really the real resolution

Fun fact ... unreal gives you the artifacts of 3d_scaleing without the performance so dropping the resolution (which is a config in a file that does not exists by default ... ) does not give you any performance gain ... at lest it keeps the UI i guess ... scaling and resolution is a general problem ... except for unity they actual got this part figured out.

[Real-EdgeLord]

ignore everything I said in the previse post ... I did not test well enough the problem persisted

****** AND I DID FIND THE ACTUAL SOLUTION ****

here are the settings

and for the solution to keep the scale i created a subviewport container with a subviewport .... and set it up as follows

the script is required to keep the UI scale in window mode where the player can mess up the aspect ratio but the scale would stay consistent

all UI element are under this subviewprot I made one for main menu and another for HUD and one more for split screen ... I confirmed that all of them work consistently (split screen needs an advance version of the code provided but the tools are the same)

as for changing the resolution I did it with

get_window().set_content_scale_size(d)

where d is the desired reslution (vector2)

I did do more digging into the problem and I think this is for real the only way to change the resolution in context of gaining massive performance ... I tested on PC and android under multiple environments and active element taking the FPS down to 23 and bringing it back up to 70 (the resolution sucked but we got the FPS back)

Sorry I did not share this earlier ....

[stephenhair]

I am making a 2d platformer that has an additional game mode of survival. The two have different device orientation that they are optimized for, I currently have it working mostly with dynamically changing camera but that doesnt dynamically change the resolution. I think i could dynamically change the resolution by calling to it. Does an andriod game still have access to those type of settings will installed fully (not a debugger) on a device?

[Calinou]

You can change all the viewport-related project settings at runtime by setting properties on the root Viewport node. See the Multiple Resolutions demo code that does it: https://github.com/godotengine/godot-demo-projects/blob/c3b0331d8a06a2b8def14e745db9e24d0f387c80/gui/multiple_resolutions/main.gd#L90-L134

Changing the viewport size to affect the 2D rendering resolution will only work when using the viewport stretch mode though. It will have no effect on the root Viewport if using the disabled or canvas_items stretch modes.

[stephenhair]

Thank you for the assistance! I'll let you know how it works out.

[DaveFace]

This seems like an exceptionally verbose piece of documentation, which is trying to cover both 2D and 3D which have very different requirements. While changing resolution for a 2D game is arguably unnecessary, for 3D this is an extremely basic requirement. It reads more as a "this is why we're being obtuse and not supporting a basic 3D feature" more than it does documentation.

[mechalynx]

Excuse me but I don't understand your complaint here. The documentation page may be long but it is rather to the point, trying to cover use cases as well as how viewports and resolution work in the engine. Most of these are more relevant to 2D than 3D but 3D is covered elsewhere in more detail. There is more than this one page dealing with rendering and resolution. I fail to see how it is trying to cover both 2D and 3D in a way that is problematic. It covers handling multiple resolutions, that's it.

Also, the article explicitly disagrees on whether changing resolution in 2D is unnecessary and provides reasons (which you do not), while also explaining why the engine works the way it does where base window resolution is concerned, which is actually what you mean when you say "changing resolution" (since changing the rendering resolution in the engine is very easy). If you were to read it, you would see that it states that modifying the window resolution can result in the monitor being stuck at that resolution if it crashes (modesetting), which is true for anyone who's been around 3D games for a while.

Not as much of a problem these days but also having a base window resolution of something like 1080p and scaling the resolution down from there is also not much of a problem these days. Not to mention, even other game engines, popular ones too, have changed how they manage this over time, with borderless window being how they actually handle "full screen" mode these days for example. I may not agree with this approach but it has become the norm in many released games.

To say it doesn't support a "basic 3D feature" and it's being "obtuse" not to do so, and that the documentation reads the same as an excuse not to support said "basic 3D feature", betrays the fact that either you didn't read almost any of the page because you were looking for something else, or you planned on not reading the page at all after you read previous comments under this page and decided to go straight for the "customer is always right approach" and complain despite neither being a customer nor being right.

The policy of godot's design is explicitly to never crash if possible (as stated on the main page) and use cases for features are always considered if you bothered to read actual discussions on actual feature requests and additions. Somehow, even though many of us use 3D in godot explicitly and some make entire games with it, we don't find this to be a "basic feature" we're lacking. In any case, your complaint isn't even about the documentation page you didn't read, it's about the engine. There is a proposals repository where you can request this form of explicit resolution switching and explain why it is critical or "basic". I trust that you will find the maintainers will listen and agree with you if you provide clear use cases and reasoning but you should not be surprised if they have some reasons of their own.

[DaveFace]

I'm not sure why you've jumped to the conclusion I didn't read the page I'm commenting on, just because I disagree with it / you don't understand what my disagreement is. I would suggest trying to understand what someone is saying before assuming they're being disingenuous.

[mechalynx]

You say that but you were clearly not understanding the purpose of the article and the one being disingenuous is yourself:

It reads more as a "this is why we're being obtuse and not supporting a basic 3D feature" more than it does documentation.

That doesn't seem like not jumping to conclusions or assuming the best and simply disagreeing. You get treated the way you treat others and when you attack first, expect others to treat you in kind. It's not really unfair is it. I was being polite when I was saying I don't understand what your complaint is, as polite as I could, given the above statement you made, which was an entire 1/3rd of what you said and what you ended on as a conclusion.

[DaveFace]

I'm not sure why you're taking some light criticism of an article as a personal attack, but if you want to have a "polite" conversation, you don't start by accusing the other person of lying. Two people can read the same thing and come to different conclusions.

[mechalynx]

I didn't take it personally, I'm not part of the project. I am objecting to your criticism. Also, that is a suspicious deflection considering you were attacking the intentions of the article, thus making an attack that aims at the person or people behind the article, not merely making a critical comment on its contents or format. I also did not say I intended to have a polite conversation, I was applying "light criticism" to your rather unconstructive and definitely not light criticism. Once again, to remind you of what you said for context:

It reads more as a "this is why we're being obtuse and not supporting a basic 3D feature" more than it does documentation.

If you intended this as light criticism and this is your standard for it, then my own criticism of your criticism counts as light as well. I just am not hypocritical enough to claim that I didn't say something I did. I didn't accuse you of arriving at a different conclusion having read the article, I accused you of not having read it entirely or properly and perhaps not at all, which is evident given that you did not have specific criticisms to specific points made but rather a general criticism that attacks the intentions of the article as being to make an excuse for not implementing something you think they should (your words, not mine) and your "criticisms" seem to stem directly from what a specific other comment has objected to.

Additional evidence of that is that you keep vaguely accusing me of simply disliking that you disagree rather than being specific and detailed about what your criticisms of the article are. You also have ignored all of my points pretending my "light criticism" of your "light criticism" isn't "light" enough. You just keep projecting and pretending you didn't make an attack on the author's and project's character, which you did.

---

There are avenues available to you: You can open a proposal about supporting this feature in https://github.com/godotengine/godot-proposals/issues as an issue, you can make a pull request with the desired changes you want in https://github.com/godotengine/godot-docs/issues. There are guidelines here: https://docs.godotengine.org/en/stable/contributing/documentation/contributing_to_the_documentation.html#what-is-the-godot-documentation and here https://github.com/godotengine/godot-proposals?tab=readme-ov-file#rules-for-submitting-a-proposal. All of this can be done without even having to run git locally or clone the repositories locally.

As to why I take this kind of thing to heart: lots of accusations are made against the project for the people running it being lazy, stupid, "obtuse", uncaring, unhelpful and even impolite. Yet, these seem to be made often through ignorance and even sometimes through malice. While this is very common for open source projects, I have been around this project for a while and I can't say I've seen anyone except the occasional entitled user being impolite, I haven't seen the project's maintainers ignoring people's requests or bug reports and most of the time, things people claim the maintainers don't care about are things already addressed in detail, with technical explanations or cases where use cases and meaningful arguments are expected but not provided.

For as few people as they are, they seem to spend an enormous amount of time trying to address issues (one only needs to look at the issue tracker regularly to observe this in action), trying to do so in a way that does not overcomplicate the core (so that the project remains maintainable and accessible to contributors) and trying to take as many people's needs into account. It isn't perfect nor are the people involved (I would even go so far as to say I dislike many of them) but it's an honest effort that bears fruit.

They will not respond the way I do so I feel some of us ought to set the record straight when comments like yours are made because it honestly gets tiring.

[BManx2000]

In the section about "targeting high end devices", I would add another step: set "gui/theme/default_theme_scale" to 2.0. This will prevent the built-in controls from being unusably tiny.

[Calinou]

Pull request opened:

• Mention Default Theme Scale project setting in Multiple Resolutions godot-docs#11272