Incorrect 2D SubViewport scaling behavior

[uzkbwza]

Godot version

4.2.dev5

System information

Windows 11, AMD 7950x, RTX 4090

Issue description

All 2D SubViewports behave normally in-editor, but in-game act as if they are using the canvas_items stretch mode in Project Settings; they do not respect the resolution set in size_2d_override. There is no apparent way to change this behavior. I am trying to make a game that has a pixel-perfect low-resolution game-view with high-resolution pillarbox art. This appears to be impossible to do with Viewports currently, and is an important inconsistency as this behavior is desired for many pixel art games.

Godot_v4.2-dev5_win64_otKZtlhkH2.mp4

Steps to reproduce

Use a SubViewportContainer with stretch enabled and a SubViewport with the size_2d_override set to a low resolution and size_2d_override_stretch enabled. The SubViewport resolution will appear different when the game is run than it does in the editor.

Minimal reproduction project

subviewport problem.zip

[Jordyfel]

Please remove the .godot folder when submitting MRPs, also your script does a bunch of redundant stuff which makes it very hard to understand what you want to do. What I'm seeing is that the behavior between the editor and the game is not inconsistent, because your script increases the viewport container's size at runtime. If you were to do that in the editor, you get the same result.

I managed to do what you want (I think) using Sprite2D, try this:
subviewport_problem.zip
subviewport_problem.zip

The integer scaling solution on the project settings is applied only to the root Window, the related properties are in base Window, they had practically nothing to do with your project.

Something is indeed wrong with size2d override not being respected properly in a SubViewportContainer, not sure whether it's intended or not.
The size override is being respected fine, it just that it's not possible to control the behavior like with the properties present in Window and it defaults to the canvas_item stretch mode behavior.

TLDR: There is no bug here, yes, it's impossible to do it with SubViewportContainer, it's not that hard to implement integer scaling logic yourself for a subviewport. I can imagine using ViewportTexture is not obvious, don't mean to be rude.

[uzkbwza]

Here is a more minimal project that demonstrates the problem, then. I will update the OP.

subviewport problem.zip

Thank you for including a workaround solution, but I don't think it is a good enough replacement. ViewportTexture doesn't allow for the straightforward use of mouse inputs or sound, which is a major drawback.

The size override is being respected fine, it just that it's not possible to control the behavior like with the properties present in Window and it defaults to the canvas_item stretch mode behavior.

If this is not considered a bug, then I will be opening a proposal.

[Cyangmou]

This is an issue related to the forward_plus renderer.
I experienced the same.
It doesn't appear with the compatibility renderer.

@akien-mga can you add the rendering / windows tags to this? It's kind of related to things I found out in my tests here:
Issue #84137