Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mouse position not being scaled when nested viewport size is different from parent viewport #59858

Open
kidinashell opened this issue Apr 4, 2022 · 3 comments

Comments

@kidinashell
Copy link
Contributor

kidinashell commented Apr 4, 2022

Godot version

v3.5.beta3.official [3c0d325]

System information

Windows 10, GLES3

Issue description

Info: The problem persists in earlier stable versions of Godot as well (3.3x and 3.4x)

What doesn't work?
Mouse position is not scaled when using a viewport inside another viewport (through a ViewportContainer) and the child viewport has a different resolution (smaller or bigger) than the parent viewport.

2022-04-04_07-25-59.mp4

How do I expect it to work?
Mouse position is scaled to allow for child viewports inside parent viewports where the child viewport has a different resolution (for example super sampling / "down" sampling.

2022-04-04_07-27-09.mp4

Steps to reproduce

I've added a sample project which is also used for the showcases (videos) up top. The following steps can be used to reproduce from scratch and explains the necessary project setup which will lead to the mentioned behavior.

  • Create a new project
  • Set window width and window height to desired resolution
  • Set stretch mode to 2d and stretch shrink to expand
  • Add a ViewportContainer to the scene with Stretch enabled in the inspector, set to layout to "Full Rect" and the Mouse Filter to "Ignore"
  • Add a Viewport to the ViewportContainer and set the resolution to something different (smaller or bigger) than the window resolution (or parent ViewportContainer if you have multiple viewports nested)
  • Disable "Handle Input Locally" and enable "Object Picking" on the child viewport.
  • Add an object or a script which will show you easily that the mouse position is not where your cursor actually is.
  • In my example I used a MeshInstance with a StaticBody and check for mouse interactions and based on that change the material albeido color.

FIX FOR NOW:
This bug can be circumvented with attaching the child viewport rectangle to the parent viewport rectangle. The following is from my example project which you can find below, to get a little deeper into this special case:

`var vrect = get_viewport().get_visible_rect()

#--- necessary for NON-HiDPI monitors ---#
print(vrect.size) # 1968 x 1080 on NON-HiDPI / 1920 x 1080 on HiDPI
vrect.size = get_viewport().size
print(vrect.size) # 1540 x  845 on NON-HiDPI / 1920 x 1080 on HiDPI
#----------------------------------------#

viewport.size = get_viewport().size * su_sa_scale

#--- necessary step to make sure, that mouse positions gets picked correctly;
#--- not quite sure why?
#--- UNCOMMENT LINE BELOW!

# viewport.set_attach_to_screen_rect(vrect)`

Minimal reproduction project

viewport_mouse_pos.zip

@Calinou
Copy link
Member

Calinou commented Apr 4, 2022

Related to #34805 (possible duplicate?).

@kidinashell
Copy link
Contributor Author

@Calinou Yes and no. The issue was mentioned for version Godot_v3.2-beta5_x11. Other people also mentioned this version or the following version 3.3. Then, the issue was added to the 4.0 Milestone, issue got copied over to 4.0, fixed there and closed, but it was nevrer fixed in the earlier versions, as far as I can see.
Currently I see three different branches, where issues get fixed separately. 3.4, 3.x and 4.0.
This issue was already fixed for 4.0 in #57082.
Since 3.x get's released separately from 3.4 and 4.0 in the news section of godotengine.org I think it would be a good idea, to keep this separately, so it doesn't get merged with the other one, then fixed in one branch but not the other.

@Calinou
Copy link
Member

Calinou commented Apr 4, 2022

Currently I see three different branches, where issues get fixed separately. 3.4, 3.x and 4.0.

Work on the stable Godot is only done on the 3.x branch, with bug fixes being cherry-picked to 3.4. The 3.4 branch generally doesn't have any work being done directly on that branch (since it would be lost after migrating to 3.5).

If #59858 is fixed in master, then its milestone should be changed to 3.x.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants