2D Sprite "jittering", very noticeable when using camera smoothing

[forbjok]

Godot version:
3.1.2 stable, GitHub master (3.2), Vulkan branch (4.0)

OS/device including version:
Windows 10 x64 v1909

Issue description:
Pretty much as soon as I made my test level larger than a single screen, I noticed something was off. After a bit of testing, I've found out what it is. It seems like any time the camera moves, there is some sort of inconsistency in the positions sprites are being rendered at, causing them to "jitter" back and forth by one pixel even though the camera is only moving in one direction.

Example gifs showing the issue:

How noticeable it is depends on circumstances. Generally, from what I've found, it's most noticeable if you have camera smoothing turned on and the smoothing speed set to a very low value, but the problem isn't related to the camera smoothing. It's also present with camera smoothing turned off, just harder to notice.

In case it was a bug that had already been fixed, I tried compiling Godot myself from both the master (presumably what will become 3.2) and vulkan (4.0?) branches to try them out, but unfortunately the problem still seems to be present in both of those. It looks a bit different in the Vulkan branch, due to what I assume is some sort of smoothing/blur filter being applied (there may be a way to turn that off, but I couldn't find it) to the background, but it is definitely still there.

Steps to reproduce:

1. Start minimal reproduction project
2. Run far enough to the right that the camera starts scrolling and stop.
3. Watch the vertical lines of the background brick wall or the ground near the player to see the sprite jittering back and forth by one pixel until the camera fully stops

Minimal reproduction project:
godot-jitter-repro-project.zip

[Seel]

Seems to me like the camera itself isn't respecting the pixel snap setting.

[forbjok]

The issue happens regardless of whether Pixel Snap is enabled or not.
If the issue was caused by the camera, shouldn't everything be jittering?
As far as I can tell, it's only the sprites that jitter. The background tilemap and text label does not.

[Seel]

The issue happens regardless of whether Pixel Snap is enabled or not.
If the issue was caused by the camera, shouldn't everything be jittering?
As far as I can tell, it's only the sprites that jitter. The background tilemap and text label does not.

The tilemap is one cohesive unit so it does jitter, but individual tiles within might not. I tried this right now with multiple tilemap layers, background and foreground, and that way you can really see them jitter too.

Since pixel snap doesn't seem to affect the camera, it's position.x can be something like 10.375940 and relative to this position one object that's pixel snapped might get it's position rounded up to the nearest pixel, while another one's gets rounded down.

At least that's my interpretation of what's happening.

[forbjok]

The tilemap is one cohesive unit so it does jitter, but individual tiles within might not.

I tried looking at the edge of the screen during scrolling, and I was not able to spot any jittering on the background itself relative to the edge. Shouldn't it be possible to see it jitter if comparing it to the edge?

In my example project the background and foreground actually are two separate tilemaps (although they use the same tileset), and I've never been able to spot any jittering between them.

Maybe pixel snap works differently than I thought, but I would have thought that if this was caused by pixel snapping, it would stop happening when Pixel Snap was turned off?

it's position.x can be something like 10.375940 and relative to this position one object that's pixel snapped might get it's position rounded up to the nearest pixel, while another one's gets rounded down.

My first thought was also that it was caused by some sort of weird inconsistent rounding of pixel coordinates. Basically, some sort of rounding being applied somewhere that's either RNG or just inconsistent in that sometimes higher values get rounded down instead of up. I couldn't find anything obvious when poking around in the source code though.

[Seel]

Not saying pixel snap is the cause, rather it doesn't really do anything.

pixeltest-isodemo.zip

I messed with the 2D isometric demo a bit, you can really see the jitter between walls and pillars and the floor tiles in this.

[forbjok]

Ah, yes. There's definitely some jittering going on there. I wonder why I'm only seeing it with the sprites in my game.

[lawnjelly]

I've not done any 2D stuff with Godot but it looks like the problem is something like this : your character sprite position is not snapped relative to your background.

i.e. if snapping is every 1.0 in units, and your background is at position 4.0, and your sprite is at 6.7:

At camera position 2.0

(assuming we are using a floor function to snap, but same will happen with round)
background = 4.0 - 2.0 = 2.0 = 2
sprite = 6.7 - 2.0 = 4.7 = 4

at camera position 1.6

background = 4.0 - 1.6 = 2.4 = 2
sprite = 6.7 - 1.6 = 5.1 = 5

Thus as the camera moves you are getting relative movement between the two by 1 pixel. The solution is to snap the background and the sprite positions relative to each other.

[Seel]

Thus as the camera moves you are getting relative movement between the two by 1 pixel. The solution is to snap the background and the sprite positions relative to each other.

Pixel snap should be handling this, shouldn't it?
And it does, if you have an integer camera position, but since the camera is not snapped you get unpredictable results.

If for example you put this in the camera's _process function:
position = player.position.round()
force_update_scroll()
Everything works and there's no jitter with this, but you cannot use the camera node's smoothing function.

[forbjok]

I tried manually .floor()-ing the positions of the camera and sprite in various gdscript handlers yesterday, and so far I haven't found anything that actually fixes the jitter. Maybe I could try implementing a custom camera that just sets the underlying render position directly (pretty sure I saw some way to do that somewhere, but I forget what it's called) and .floor()s it. Will definitely try that later.

If that fixes it, this kinda seems like something that should just be done automatically by default. I can't think of any reason you'd ever actually want objects arbitrarily jittering relative to each other during scrolling.

[Seel]

I tried manually .floor()-ing the positions of the camera and sprite in various gdscript handlers yesterday, and so far I haven't found anything that actually fixes the jitter.

Did you try without camera smoothing enabled? Otherwise the smoothing happens after your script and turns the camera position into a float again.

my scene tree is ordered like this:

player
    sprite
    collision shape etc.
camera

This way the camera gets the player position after the player moved.

onready var player = get_node("../Player")

func _process(delta):
	position = player.position.round()
	force_update_scroll()

This should work.

[lawnjelly]

Ok I downloaded your demo project and got it working:

1. In your player scene, create a new Node2D and call it Player
2. Make this new Node2D the scene root (so that the kinematic thing is a child of it)
3. Move the Sprite to be a child of this root node.
4. Change the

onready var sprite: = get_node("Sprite")

to

onready var sprite: = get_node("../Sprite")

5. In _physics_process at the end add:

	sprite.position = Vector2(floor(position.x), floor(position.y))

Obviously you'll want to tweak it a bit but the general idea is this .. to separate the physics representation (kinematic) from the visual representation. The physics rep can have float coordinates, but the visual representation should be floored or rounded to whole numbers.

With this working, there will always be an integer relative relationship between the background and the sprites, and you won't get this jitter.

[forbjok]

Did you try without camera smoothing enabled?

I don't remember if I tried rounding the camera position with smoothing turned off, but the jitter is present without smoothing. It's just more noticeable when smoothing is enabled.

This should work.

I'll try that when I have the opportunity, although I'll probably still have to either implement a custom camera or just implement custom smoothing on the existing one.

Ok I downloaded your demo project and got it working:

1. In your player scene, create a new Node2D and call it Player
2. Make this new Node2D the scene root (so that the kinematic thing is a child of it)
3. Move the Sprite to be a child of this root node.
4. Change the

onready var sprite: = get_node("Sprite")

to

onready var sprite: = get_node("../Sprite")

1. In _physics_process at the end add:

	sprite.position = Vector2(floor(position.x), floor(position.y))

Obviously you'll want to tweak it a bit but the general idea is this .. to separate the physics representation (kinematic) from the visual representation. The physics rep can have float coordinates, but the visual representation should be floored or rounded to whole numbers.

With this working, there will always be an integer relative relationship between the background and the sprites, and you won't get this jitter.

I'll try this as well when I have the opportunity, but wouldn't rounding the position set to the viewport's canvas_transform (I believe this is what Camera2D sets internally?) also fix the issue?

[lawnjelly]

I'll try this as well when I have the opportunity, but wouldn't rounding the position set to the viewport's canvas_transform (I believe this is what Camera2D sets internally?) also fix the issue?

I'm not sure exactly what you mean, but it may be possible to achieve the same math effect via a slightly different mechanism (again, I am not familiar with 2D). But once you have a moving camera, snapping positions to pixels on the screen no longer works because you will get this jiggling, you need to snap relative to the SCENE.

[golddotasksquestions]

I don't use Camera smoothing with pixelart for that reason. Which is a shame, because if it wasn't for this issue, there would be no reason not to use smoothing.

[forbjok]

I tried manually .floor()-ing the positions of the camera and sprite in various gdscript handlers yesterday, and so far I haven't found anything that actually fixes the jitter.

Did you try without camera smoothing enabled? Otherwise the smoothing happens after your script and turns the camera position into a float again.

my scene tree is ordered like this:

player
    sprite
    collision shape etc.
camera

This way the camera gets the player position after the player moved.

onready var player = get_node("../Player")

func _process(delta):
	position = player.position.round()
	force_update_scroll()

This should work.

I can confirm that this fixes the jitter, although it makes the built-in smoothing unusable, so I'll have to reimplement that manually.

Ok I downloaded your demo project and got it working:

1. In your player scene, create a new Node2D and call it Player
2. Make this new Node2D the scene root (so that the kinematic thing is a child of it)
3. Move the Sprite to be a child of this root node.
4. Change the

onready var sprite: = get_node("Sprite")

to

onready var sprite: = get_node("../Sprite")

1. In _physics_process at the end add:

	sprite.position = Vector2(floor(position.x), floor(position.y))

Obviously you'll want to tweak it a bit but the general idea is this .. to separate the physics representation (kinematic) from the visual representation. The physics rep can have float coordinates, but the visual representation should be floored or rounded to whole numbers.

With this working, there will always be an integer relative relationship between the background and the sprites, and you won't get this jitter.

This does fix the jitter for the player, but would have to be implemented separately for every sprite, making it rather impractical.

Ultimately, this is the solution (or workaround) I arrived at:

extends Camera2D

# Smoothing duration in seconds
const SMOOTHING_DURATION: = 0.2

# The node to follow
var target: Node2D = null

# Current position of the camera
var current_position: Vector2

# Position the camera is moving towards
var destination_position: Vector2

func _ready() -> void:
	current_position = position

func _process(delta: float) -> void:
	destination_position = target.position
	current_position += Vector2(destination_position.x - current_position.x, destination_position.y - current_position.y) / SMOOTHING_DURATION * delta
	
	position = current_position.round()
	force_update_scroll()

It's a combination of Seel's suggestion with a custom reimplementation of camera smoothing based on one I created in a MonoGame-based engine years ago. This completely fixes the issue for all sprites without having to do anything specific in each sprite, while still having a nice smooth camera.

This still seems like something Camera2D should be doing internally by default though, as I can't imagine the current behavior ever being desirable.