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

Viewport size returning incorrect values after resizing window and using stretch settings "2d" and "expand" #28665

Open
ghost opened this issue May 4, 2019 · 2 comments

Comments

@ghost
Copy link

ghost commented May 4, 2019

Godot version: v3.1.stable.official

OS: macOS Mojave 10.14.4
Device: 13" 2017 MacBook Pro w/ 4 Thunderbolt 3 Ports
GPU: Intel Iris Plus Graphics 650
Display: 2560x1600 Retina

Issue description:
When using stretch settings 2d and expand, get_viewport().size appears to return an incorrect value after resizing the window. If you look at the reported mouse position or move an object around in the scene and track its position, the x and y values at the edges of the window do not match the size of the viewport. It's almost as if objects are using a different coordinate system than the viewport. This was causing issues when I was trying to use the viewport's height in a project. I ended up having to manually calculate the actual size of the viewport used to position objects in scenes.

If I didn't explain this well enough, please look at the attached minimal reproduction project. It simply displays the following values to highlight the discrepancies between them:

  • The viewport size as reported by get_viewport().size
  • The size defined in the project settings file
  • The actual size of the viewport as calculated by the get_actual_viewport_size() function inside of InfoUI.gd
  • The position of the mouse
  • The position of a square that you can move around using the arrow keys or WASD

I hope that this project gets the issue across more clearly.

Take notice of how both the mouse and square positions at the right and bottom sides of the window do not match the size reported by the viewport. This can cause issues if, for example, you wanted to place an object at the right side of the window. Setting its x position to get_viewport().size.x would place it in the wrong location.

I'm fairly new to Godot, so perhaps I'm misunderstanding how viewports work and this isn't an issue. However, I could not find a way to get the actual size of the viewport as calculated in the example project, which I what I needed for a project of mine.

I don't have another machine at the moment, so I'm not sure if this is macOS-specific or not or if it has something to do with having a retina display. For reference, I'm using the lowest display scale setting in macOS (to make the screen as high-res as possible).

Steps to reproduce:

  1. Create a Godot project with stretch settings "2d" and "expand".
  2. Run the project and resize the window.
  3. Notice that the viewport size does not match the coordinate system used to position objects.

Minimal reproduction project: ViewportBugProject.zip

@ghost ghost changed the title Viewport size returning incorrect values after resizing window using stretch mode 2d and aspect expand Viewport size returning incorrect values after resizing window and using stretch settings "2d" and "expand" May 4, 2019
@KoBeWi
Copy link
Member

KoBeWi commented Aug 19, 2020

This might not be a bug actually. The reported viewport size is a correct one. When you enable stretch, the contents just get scaled. This should be probably documented and maybe there could be a method that returns the scaled size.

@Calinou
Copy link
Member

Calinou commented Aug 19, 2020

This is how I handled the issue in my WIP 3D waypoints demo:

# `get_size_override()` will return a valid size only if the stretch mode is `2d`.
# Otherwise, the viewport size is used directly.
var viewport_base_size := (
		get_viewport().get_size_override() if get_viewport().get_size_override() > Vector2(0, 0)
		else get_viewport().size
)

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