Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Partially revert change allowing sprite get_rect snapping to be controlled by
pixel_snap
again rather thantransform_snap
(to prevent breaking compatibility). Adds a finaluse_camera_snap
project setting to allow snapping viewports as in reduz original PR.Based on feedback these are some improvements to #43554 (which is a backport of #43194).
Fixes #44686
This user was unable to reproduce the same behaviour as 3.2.3. This is a valid complaint.
Although moving the get_rect snapping to the
transform_snap
project setting was logical (in #43194), it loses some flexibility. Ultimate flexibility would be to have a setting for each, but in practice I currently believe most people usingtransform_snap
will also be usingpixel_snap
, so this will save an extra project setting.Viewport (Camera) Snapping
This is a little more controversial in my opinion, and I accidentally / on purpose missed it out of the original PR. But I guess it is ok here with a separate project setting.
There are current two problems with camera snapping:
There is currently another bug (likely in the update order) which can cause jittering between camera position and target position (may be the force_update_scroll() bug Camera2d has a one frame delay #28492)
2D physics objects have delay to their positions #43800 (comment)
Using the
camera_snap
option means you cannot smoothly interpolate the camera in 'sub texel' movement (assuming blocky pixels, which I will refer to as texels here). This means you can't have smoothly interpolating cameras or smooth camera 'shock' effects.You can achieve (2) by doing camera snapping manually however (see #43554 (comment)), and also bypass the bug of (1). However this is more advanced, and may be beyond beginner users to understand and pull off.
See this example project for an example of manual camera snapping:
Jittering Camera Bug Workaround.zip
In this same project if you change the active camera to the camera hanging off the player, and switch on camera snapping, you will likely see bug (1) exhibiting. This bug is more apparent when the physics tick rate diverges from the refresh rate.
Also the very act of merging camera_snapping may also expedite fixing bug (1). It is a chicken and egg situation, as few are aware of the bug at the moment and the need to fix it. I haven't fixed it as part of this PR because I'm unsure of the exact cause as yet.
Extra Demo
This shows (2) nicely. By doing manual camera snapping, it allows the camera to exactly follow a player, but apply a float offset. Note that if you turn on the
camera_snapping
in the project settings of this project, you will see the limitation (you lose the ability to have float offsets). This is a large part of the reasoning to have a separate setting forcamera_snapping
fromtransform_snapping
.Jittering Camera Bug Workaround2.zip