Support Snap 2D to Pixel

[elvisish]

Issue description

I have target set to the player sprite, move_and_slide() is in physics_process(),stretch set to viewport, physics interpolation turned on, snap to pixel turn on in PhantomCamera2D, snap 2d pixels and vertices to pixel turned on:

https://github.com/user-attachments/assets/6ce93e5b-563a-45d3-b9e3-7c3691a37bee

Even with turning some of these off, it still stutters.

Steps to reproduce

• target set to the player sprite
• move_and_slide() is in physics_process()
• stretch set to viewport
• physics interpolation turned on
• snap to pixel turn on in PhantomCamera2D
• snap 2d pixels and vertices to pixel turned on

(Optional) Minimal reproduction project

No response

[ramokz]

It seems like it's specifically the last part of the setup that is the cause of the issue, i.e. Snap 2D Vertices to Pixel / Snap 2D Transforms to Pixel.

Not entirely sure what is needed to support it, but there is likely a way.

[ramokz]

Investigating a bit further, there appears to be some general challenges with the Snap 2D to Pixel project setting: https://github.com/godotengine/godot-docs/issues/7774. So not sure if this is something the addon can / should resolve, but still looking into it.

Out of curiosity, does disabling Snap 2D to Pixel not produce a desired result?

[elvisish]

Investigating a bit further, there appears to be some general challenges with the Snap 2D to Pixel project setting: godotengine/godot-docs#7774. So not sure if this is something the addon can / should resolve, but still looking into it.

Out of curiosity, does disabling Snap 2D to Pixel not produce a desired result?

It still happens with both disabled:

https://github.com/user-attachments/assets/75007da0-abc0-4a80-a017-3fb6a2f576cc

[ramokz]

That's strange.

Your setup sounds identical to all the example scenes. Do you see the issue in those also?

[elvisish]

That's strange.

Your setup sounds identical to all the example scenes. Do you see the issue in those also?

I matched all of the PhantomCamera2D settings and even tried floor(velocity) to avoid using floats, but it still stutters. Even the hierarchy is the same, I'm not sure what else could be causing it?

[ramokz]

Does the example scenes within the addon directory themselves run fine for you, or do they stutter as well?

Also, would you be able to share a small sample project / MRP? Can run some tests locally to see what's up.

[elvisish]

Does the example scenes within the addon directory themselves run fine for you, or do they stutter as well?

Also, would you be able to share a small sample project / MRP? Can run some tests locally to see what's up.

With snap turned off, you might have to move back and forth a little to see it happen. Almost feels as though there's a floating point discrepancy? mariotest.zip

[ramokz]

Running some quick checks, it appears not to be due to the Snap 2D to Pixel in Project Settings, but rather the Snap to Pixel in the PCam2D.

My guess is that it has something to with the character itself not moving in exact pixels, bur rather floats, which would suggest that the camera is getting confused as to which pixel it should snap to.

When I hardcode the position of the character by rounding its value, it does make the stutter go away:

# Rest of the _phyiscs_process code
move_and_slide()

position.x = round(position.x)
position.y = round(position.y)

handle_last_collision()
print(velocity.x)

It's a hacky way of getting around it, but my guess is that the velocity calculation that is happening in the move_and_slide function makes that inevitable, at least by default.

[elvisish]

Running some quick checks, it appears not to be due to the Snap 2D to Pixel in Project Settings, but rather the Snap to Pixel in the PCam2D.

My guess is that it has something to with the character itself not moving in exact pixels, bur rather floats, which would suggest that the camera is getting confused as to which pixel it should snap to.

When I hardcode the position of the character by rounding its value, it does make the stutter go away:

# Rest of the _phyiscs_process code
move_and_slide()

position.x = round(position.x)
position.y = round(position.y)

handle_last_collision()
print(velocity.x)

It's a hacky way of getting around it, but my guess is that the velocity calculation that is happening in the move_and_slide function makes that inevitable, at least by default.

Is this the same as Snap 2D transforms to pixels? I wonder if it would be possible to figure out which order that happens, and somehow change when Phantom Camera updates. This works well without jitter (although I don't know if snapping is necessary when viewport scaling is used):

[ramokz]

Is this the same as Snap 2D transforms to pixels?

Not quite. If you log the position of your playable character, you can see that it still moves in floating-point values even when that is enabled, which, I think, is attributed to the move_and_slide() function.

My guess is that either the Snap 2D Transform/Vertices to Pixel is being ignored by it, or that method just works differently and doesn't, at least by default, move in whole pixels.

Recorded an example below to show what the position of the sprite is when the rounding is disabled / enabled; both with Snap 2D enabled in Project Settings.

https://github.com/user-attachments/assets/bc8141ec-25e8-4355-a157-81f864bd8ee1