More snapping options as project settings

[lawnjelly]

Defaults are better (and separate) for stretch_mode viewport and stretch_mode 2D. All rounding settings can be overridden giving the user full control.

I've spent a couple of days going over the various snapping options in 3.2.4 trying to improve them. The end result in my opinion is that the results when using stretch_mode 2D are very good. In most games I would recommend this mode, as it gives sub texel accuracy and works well with camera smoothing.

stretch_mode viewport works less well with snapping. The transform snapping introduced to prevent relative movement between backgrounds and players seems to introduce as many problems as it solves. In particular, if the camera is not tightly linked to the player in terms of timing, you are likely to see a juddering effect due to aliasing, and because these games are very blocky, the effect can be very pronounced. For this reason I would advise against trying camera smoothing with snapping turned on.

I also tried (particularly for stretch_mode viewport) adding snapping to the camera smoothing function in Camera2D with some success, but imo it is a band aid on a problem that isn't easily solvable. The feedback between the smoothed camera and the snapping tends to produce juddering (as does vibrating physics).

Overrides

Although we hoped to make the snapping options as simple as possible, the difficulty is that the best settings seem to be game dependent. So I've added an advanced option to override the rounding mode for each case. I don't think any of them are ideal for stretch_mode viewport, but at least the options are in the hands of the users.

Notes

• This is a splitting apart of the snapping functionality from Fix 2d camera frame delay #46569, which I will modify to just include the camera changes, so they can be evaluated separately.
• I've added Experimental to the project setting tooltips.
• The reason for the separation between x and y overrides is that in Godot y decreases as you move up the screen. So often you may need to use an opposite rounding mode (i.e. ceiling) for y, because we expect objects above the ground by 0.01 (due to physics margins) to round down to ground level, and not a pixel up leaving a gap.

[securas]

Made some basic tests and although I may have not used the adequate options, I see the same behavior as reported here: #46504 (comment)

In addition, I observed the same behavior using either 2d or viewport stretch modes. The only difference being that in the 2d mode the behaviors were naturally smaller.

the only novelty was when deselecting camera snap and transform snap this additional behavior of the character jumping 1px up

This would imply that with all novel options deselected, the behavior does not match previous godot versions.

[lawnjelly]

This would imply that with all novel options deselected, the behavior does not match previous godot versions.

I'll double check this, but even with snapping totally off, there is no guarantee you will get the same behaviour between Godot versions, there may have been changes to 2d physics / collision margins which could cause this in viewport stretch mode.

[securas]

This would imply that with all novel options deselected, the behavior does not match previous godot versions.

I'll double check this, but even with snapping totally off, there is no guarantee you will get the same behaviour between Godot versions, there may have been changes to 2d physics / collision margins which could cause this in viewport stretch mode.

Fair enough. More concerning though is the behavior even with 2d stretch mode.

[securas]

This would imply that with all novel options deselected, the behavior does not match previous godot versions.

I'll double check this, but even with snapping totally off, there is no guarantee you will get the same behaviour between Godot versions, there may have been changes to 2d physics / collision margins which could cause this in viewport stretch mode.

I was looking at the camera code and found that is has the simplest smoothing function. That particular function (it seems) never really reaches the target. I was wondering if that may be a possible source of camera instability. What do you think?

[lawnjelly]

Fair enough. More concerning though is the behavior even with 2d stretch mode.

2d stretch mode will have similar behaviour but you can have the jiggling on a smaller scale (i.e. pixel rather than texel), by using the post transform snapping settings. This makes it less objectionable.

For viewport stretch mode as I say, I often couldn't get behaviour that looked good either.

So the long and short is : I have basically have exposed every possible snapping option (that I can think of), and you have to either find some that work for you or don't use it. It is an advanced option that may not benefit everybody.

If you believe that snapping will help in every situation, that is a misunderstanding. This is part of the reason why I made the separate PR to hide these options. Some of the threads written by others have imo led to unrealistic expectations of the benefits (this same hype problem occurs regularly for different engine features, it just seems human nature).

The reason you will typically get behaviour you don't want, is normally to do with using Godot or Bullet physics. This is the trade off with using a physics engine - you will get vibrations, float error etc. I don't actually recommend snapping with physics, and especially not in viewport mode. If you are on the other hand handling the movement code yourself, you can be pixel perfect and more success with snapping.

It is important to realise that although snapping may not help your particular game, that is not a reason to prevent others from having access to the functionality (it may help in their circumstances).

[lawnjelly]

I was looking at the camera code and found that is has the simplest smoothing function. That particular function (it seems) never really reaches the target. I was wondering if that may be a possible source of camera instability. What do you think?

Yes, camera smoothing introduces a feedback loop between target position and camera position which causes judder. Same with physics. This is why it is crucial to understand exactly what is going on in terms of fractional numbers to get good behaviour.

This is also why I recommend for best results not to use physics or camera smoothing, and to do this yourself so you can have precise behaviour, which is crucial. You may also have some success with applying a more sensible smoothing function on top of physics positions (e.g. smoothing with hysteresis).

Also: Note that you aren't seeing this with the fixed camera. Until the fixed camera is merged you have a frame delay on the camera, which compounds any problems in this area. Your demo project looks pretty good with 2d stretch and fixed camera. 😀 I'll have to see if I can make a video.

[lawnjelly]

I'm really not happy with the current transform snapping...
I think there's 2 main problems:

1. It is too complicated for users to understand
2. We are snapping by object centres

It hadn't occurred to me as I was basically just extending m6502 and reduz PR's, and I'm not that familiar with this side of the engine, but the transforms are based on object centres, which I suspect is an incorrect approach. Normally I would have thought bottom / top left of exactly scaled pixel graphics would be the right approach for snapping. If a sprite, or viewport, is an odd size, then the bottom left pixels won't match up and you'll get phasing, which is the problem all these rounding options are probably trying to correct for.

I think this needs a lot more time and we are getting close to 3.2.4 release so I think we should revisit it when there is more time for betas. Releasing a half baked feature just seems not a good idea.

[akien-mga]

Yeah let's take time to revisit this thoroughly for 3.2.5 when we have more time to experiment.

We might still want to rename the features already in 3.2.4 RC 3 to include "experimental" to make clear that there are known issues, and that whatever they do might change in future releases (so we can change their behavior/rename them without breaking compat).

[securas]

What does this mean for the transform snapping altogether... Is it also pushed?

[lawnjelly]

We might still want to rename the features already in 3.2.4 RC 3 to include "experimental" to make clear that there are known issues, and that whatever they do might change in future releases (so we can change their behavior/rename them without breaking compat).

We could even just simply revert them for now. That might be wiser in terms of a stable release. I can prepare both PRs then is up to you, I would revert I think.

[lawnjelly]

What does this mean for the transform snapping altogether... Is it also pushed?

Pushed back to after 3.2.4 stable.

[securas]

Ok. In any case, I would like to commend your approach and perseverance to this @lawnjelly ! Also, by providing all the options conceivable was a great approach. Users will never complain of too many options and documentation is the way to solve that.
In all... Well done!