KinematicBody2D is jittering when it's position is set relative to a scrolling camera.

[JosiahJohnson]

Jitter Test.zip

Godot version

3.3.1

System information

Win 10, GLES3, i5 4570, RX 580

Issue description

I have a vertical autoscrolling stage where I'm moving the camera position with a tween. I'm also setting a kinematicbody2D's position relative to the moving camera in _physics_process. This causes the kinematicbody2D to jitter vertically, when it should appear still. Sync To Physics is also enabled on the kinematicbody2D.

This used to work correctly, but the issue started when I updated to version 3.3.1 from 3.2.3. After testing various versions, the issue starts on 3.2.4 rc4. Possibly related to the 2D snap feature that was scrapped, mentioned in the RC4 notes.

Additional info can be found here.

Steps to reproduce

Camera code: $ScrollTween.interpolate_property(camera, "position", camera.position, stopPosition, scroll_time, Tween.TRANS_LINEAR, Tween.EASE_IN_OUT) $ScrollTween.start()

kinematicbody2D code: position = Vector2(position.x + direction, camera.position.y + float_y)

Minimal reproduction project

No response

[Calinou]

Can you test this on Godot 3.3.2?

[JosiahJohnson]

Just tested on 3.3.2, it still jitters.

[lawnjelly]

The snapping was reverted in #46657, so that should be the same as in previous version - I'll double check though that there are no differences, it's a while since I looked at it.

What did change is a bug was fixed which was responsible for a frame delay in the 2d camera : #46697. I did suggest making an option for a compatibility mode with the previous version but reviewers preferred not to have this option. If there is something in your code that relied on the previous buggy behaviour, particularly in regard to order of operations, then you could see differences.

Also any changes to physics could also have affected this.

Also, be aware that the project setting for the old GPU pixel snap has changed between 3.2.3 and 3.3, it is now in rendering/2d/snapping/use_gpu_pixel_snap. There were starting to be a lot more 2d settings in 3.3 and we took the opportunity to create a new section.

EDIT: There's one difference I've found between 3.2.3 and 3.3 after reverting: In Sprite::get_rect(), this section is new in 3.3:

    if (Engine::get_singleton()->get_use_gpu_pixel_snap()) {
        ofs = ofs.floor();
    }

Whereas a similar section is present in 3.2.3 for Sprite::get_rects().

I'm just trying to work out whether this should be there, it may have been introduced by backporting reduz PR. I have to re-familiarise myself with this as it has been a while since I worked on it, it's possible I did not realise when reverting that this was new (as it isn't dependent on the new settings). On the other hand it could be a valid bugfix, it is present in 4.x branch.

I think in any case we would need a minimum reproduction project to consider making changes in this area, there could be several possibilities for the differences you are seeing, and we don't want to fix something that isn't a bug..

[JosiahJohnson]

I'll see if I can throw a test project together.

[JosiahJohnson]

I made a test project in 3.3.2 and it scrolls perfectly! I'll have to do some digging to figure out the issue with my game. It might just be a setting I missed.

[golddotasksquestions]

What I do in these situations is to duplicate everything (the complete project folder) and import is as a separate project, then delete everything bit by bit that is not essential to replicate the issue.

This takes a bit of time as you have to test to see if the issue still exists, but imho it's still the fastest way if asking the community and recreating from scratch failed.

Either you figure it out yourself along the way, or if not, you end up with a boiled down minimal project which is easy and quick to examine by contributors and others willing to help.

[JosiahJohnson]

Sounds good, I'll have to give that a try.

I stumbled upon an even bigger issue while testing it on my laptop though. My game is completely glitchy on 3.3.2 on my laptop, while it works fine on my desktop. Maybe windows 7 support wasn't thoroughly tested on the new release? It works fine with 3.2.3 on my laptop. I can submit a second issue for that though.

[Zireael07]

Windows version shouldn't matter - more likely it's your laptop GPU causing the glitches - and yes, separate issue for those.

[JosiahJohnson]

I take that back, I was able to reproduce the jitter issue on my test project (it's attached at the top). I forgot I had Sync To Physics enabled on the kinematic body. Once I checked that, it will jitter.

It only occurs on my desktop though (specs listed at the top). Funny enough, it runs fine on my old laptop that has the other issues with my game on the newest version.

[lawnjelly]

I think there's several problems going on here:

1) If you put your physics tick rate down to 10tps you will see the effect exaggerated. 2) You are updating your raft on a physics tick, and the camera on a frame process, this might be leading to issues between the two. 3) If you turn off sync to physics and change the raft update to _process the jitter goes away. I'm not exactly sure what sync to physics does, I'll try and find out.

I suspect as you are setting the position directly, you may not want to be using sync to physics (it says not to use it with move_and_slide etc).

It's possible the bug in 3.2.3 causing a frame delay on the camera was compensating for another bug where there is a frame delay on the raft movement.. or something to that effect. :slightly_smiling_face:

Actually you still get some degree of jitter in 3.2.3 regardless of settings, when physics tick rate doesn't match frame rate. For all games I would recommend thoroughly testing with a physics tick rate that doesn't match the monitor refresh rate. This will expose lots of bugs which might occur for end users (that might not have 60fps monitors).

With this kind of thing order of operations is crucial. This is approximately what may be happening with your case as is:

Frame 0 Camera moves to 0.0
Physics Tick 0 Raft moves to 0.0
Frame 1 Camera moves to 0.6
Frame is displayed (with raft and camera in different places)
Physics Tick 1 Raft moves to 0.6
Frame 2 Camera moves to 1.4
Frame is displayed (with raft and camera in different places with fractional offset, snapping causing jitter)
etc etc

[JosiahJohnson]

Thanks for the info, I didn't know about testing at different tick rates. That's the setting under Physics > Common > Physics Fps? I had sync to physics on all my moving platforms so the player won't slide off, but I don't think it matters in this case since I'm setting the position? A better option may be adding a collision to my water so it pushes the raft up.

[Calinou]

That's the setting under Physics > Common > Physics Fps?

Yes :slightly_smiling_face:

[lawnjelly]

BTW if you are finding this kind of jitter (player against camera, objects against background) difficult, it is because it is much more difficult than it appears, especially when using a physics engine. I wrote this recently which may give you some sense of the problems involved: https://github.com/lawnjelly/godot-snapping-demo

[JosiahJohnson]

Thanks, interesting read. I had assumed old games worked that way. I’m actually not too picky on perfect scrolling. Funny enough, I find a little jank can give some character. Kinda like warped textures on ps1 games. The raft was a little too much character though 😄

So are there plans to fix issues like this, or is it not possible? It seems like a common scenario others might try, at least to me. Or maybe it’s completely overhauled in 4.0?

[lawnjelly]

There's an extensive literature on this, see #35606, #41491, #43554 etc. Have fun. :slightly_smiling_face: TLDR .. we tried some fixes in core for 3.3 betas but these were reverted, as they caused problems.

[JosiahJohnson]

Good to know. Thanks for looking into it.