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

Pixel snap interferes with Sprite offset rounding on Y axis #44048

Closed
grotar00 opened this issue Dec 2, 2020 · 7 comments
Closed

Pixel snap interferes with Sprite offset rounding on Y axis #44048

grotar00 opened this issue Dec 2, 2020 · 7 comments

Comments

@grotar00
Copy link

grotar00 commented Dec 2, 2020

Godot version: 3.2.3.stable.official

OS/device including version: Windows 10 x64

Issue description:
Changing uncentered Sprite offset with 2d/use_pixel_snap project flag checked results in visual vertical displacement of the image while editor frame is displayed correctly. Entering original offset doesn't revert this glitch but everything looks right after project is reloaded.

demo

Steps to reproduce: Create project with pixel snap enabled, create Sprite node with centered parameter unchecked, assign any offset value.

Minimal reproduction project:
Sprite Offset Test.zip

@Calinou
Copy link
Member

Calinou commented Dec 2, 2020

This may be fixed in 3.2.4beta3 by #43554, please test with that version if you can.

@grotar00
Copy link
Author

grotar00 commented Dec 2, 2020

Can confirm it's solved on 3.2.4beta3.
However, new option 2d/use_transform_snap inherits this behavior while both image and frame appear shifted. Happens regardless of 2d/use_pixel_snap being enabled.

demo2

@Calinou
Copy link
Member

Calinou commented Dec 2, 2020

cc @lawnjelly

@lawnjelly
Copy link
Member

lawnjelly commented Dec 3, 2020

No idea why off the top of my head. Float rounding issues perhaps on a whole number boundary? Or something else entirely. It does look like something is being retained on the original 'client' position, or perhaps the position in the visual server. I won't have time to investigate this at the moment.

Perhaps some of the snapping enthusiasts can investigate this, I'm really snowed under at the moment. Really my PR was just a backport / sorting the project settings for @m6502's idea so it could be merged and investigated - I'm slightly regretting it now 😄 . It doesn't imply that I champion the approach, or am the 'go to' guy for snapping, it is outside my (self-imposed) remit. There will be lots of consequences of this kind of change - snapping is a deep rabbit hole.

This may be due to some of the changes from reduz PR, this may happen in master too.

@m6502
Copy link

m6502 commented Dec 3, 2020

@lawnjelly I'll try to put some hours into this and investigate what's going on, thanks for your efforts :-)

@lawnjelly
Copy link
Member

This seems fixed by using round #43813. I'll leave this open until that is merged.

@akien-mga akien-mga added this to the 3.2 milestone Mar 1, 2021
@akien-mga
Copy link
Member

Fixed by #43813.

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

5 participants