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

OrthographicCamera.ScreenToWorld and similar methods interact poorly with window not at (0,0) #793

Open
Charlie-83 opened this issue Oct 25, 2022 · 1 comment
Milestone

Comments

@Charlie-83
Copy link

ScreenToWorld and WorldToScreen adjust the screen position by the origin of the viewport. However, when the origin of the window is not (0,0) this also adjusts by whatever the offset of the window is. This is very unlikely to be what you want since things like MouseState position or TouchState position are already relative to the window and so you are required to pre-emptively undo the correction made by ScreenToWorld (or WorldToScreen) using window information.

@AristurtleDev AristurtleDev added this to the v4.1 milestone May 20, 2024
@DigitalOverrideDivide
Copy link

DigitalOverrideDivide commented Dec 12, 2024

To add to this, whatever the intended behavior of WorldToScreen, I assume that ScreenToWorld should be the direct inverse. Currently this is not the case.

The current implementation of ScreenToWorld
return Vector2.Transform(screenPosition - new Vector2(viewport.X, viewport.Y), Matrix.Invert(GetViewMatrix()));

And the current implementation of WorldToScreen, which is not the inverse of the above.
return Vector2.Transform(worldPosition + new Vector2(viewport.X, viewport.Y), GetViewMatrix());

I believe the intended implementation of WorldToScreen is the following:
return Vector2.Transform(worldPosition, GetViewMatrix()) + new Vector2(viewport.X, viewport.Y);

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

No branches or pull requests

3 participants