You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OS/device including version:
Windows 7 RTX 2080 GLES2 (but it happens on all my computers, Linux too)
Issue description: https://youtu.be/Ty0yekEMRRk
Watch the video and notice how the broken lamp (after the physics has settled and sleeping) jitters when the camera moves back and forth.
Steps to reproduce:
Create a new project. In the project rendering quality settings, check "Use Pixel Snap".
Create a Camera2D and enable smoothing. Speed: 5, Offset(s): 0, Drag Margins: 0.2
Place a Sprite or TileMap in the scene.
Place any PhysicsBody2D, such as RigidBody2D or KinematicBody2D in the scene. Put a Sprite inside the physics body. Run any sort of physics simulation on the physics body (such as adding angular momentum), then freeze the physics body.
Notice how the Sprite inside the physics body jitters when the camera moves, compared to sprite or tilemap outside the physics body.
Potential Solution:
Here's the deal, the physics body isn't the actual problem. The problem is if I draw a sprite at [0, 0] and draw another sprite at [0.5, 0.5], this sort of jittering is visible when the camera moves. Same thing happens if I rotate a sprite.
The reason I brought the physics body into this issue is to show that a game developer can't realistically be expected to work around this by rounding the x/y values in order to draw the sprite correctly without jittering. The physics simulation would break. I don't know how you would work around sprite rotation causing jittering.
Pixel Snap needs a more sane implementation. The current implementation appears to have this jittering issue because sprites are drawn to the nearest pixel on the screen as they are processed, instead of, for example, drawing all the sprites to the nearest pixel on an image, then panning that image when the camera moves.
Or round the Camera2D drawing position when Pixel Snap is enabled. If the camera isn't attempting to draw at non-integer positions during smoothing, this jitter probably wouldn't be visible. This won't fix slow rotating cameras, though.
The text was updated successfully, but these errors were encountered:
It would be nice to have a Camera2D setting/state that makes it draw from rounded coordinates. I had to hack together my own camera smoothing outside of Camera2D to avoid this problem in one of my projects.
Yes I also am in favour of snapping objects to the scene (background) instead of or in addition to pixel snap to the screen.
It can be done now with scripting providing you understand the issue, but there is no in built solution. For physics object snapping through script, you would need to separate your physics representation from the render representation, which is commonly also required in interpolation.
Godot version:
3.2.2
OS/device including version:
Windows 7 RTX 2080 GLES2 (but it happens on all my computers, Linux too)
Issue description:
https://youtu.be/Ty0yekEMRRk
Watch the video and notice how the broken lamp (after the physics has settled and sleeping) jitters when the camera moves back and forth.
Steps to reproduce:
Minimal reproduction project:
pixel-snap-physics-error.zip
Potential Solution:
Here's the deal, the physics body isn't the actual problem. The problem is if I draw a sprite at [0, 0] and draw another sprite at [0.5, 0.5], this sort of jittering is visible when the camera moves. Same thing happens if I rotate a sprite.
The reason I brought the physics body into this issue is to show that a game developer can't realistically be expected to work around this by rounding the x/y values in order to draw the sprite correctly without jittering. The physics simulation would break. I don't know how you would work around sprite rotation causing jittering.
Pixel Snap needs a more sane implementation. The current implementation appears to have this jittering issue because sprites are drawn to the nearest pixel on the screen as they are processed, instead of, for example, drawing all the sprites to the nearest pixel on an image, then panning that image when the camera moves.
Or round the Camera2D drawing position when Pixel Snap is enabled. If the camera isn't attempting to draw at non-integer positions during smoothing, this jitter probably wouldn't be visible. This won't fix slow rotating cameras, though.
The text was updated successfully, but these errors were encountered: