Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected behavior for negative values on Camera2D position_smoothing_speed #90154

Closed
BrixsterPlanet opened this issue Apr 3, 2024 · 3 comments · Fixed by #90167
Closed
Milestone

Comments

@BrixsterPlanet
Copy link

Tested versions

Reproducible on Godot 4 and up. Not tested on Godot 3 and lower

System information

Godot v4.3.dev3.mono - macOS 14.2.0 - Vulkan (Forward+) - integrated Apple M2 - Apple M2 (8 Threads)

Issue description

Setting position_smoothing_speed to a negative value causes Camera2D to infinitely accelerate away from its follow target.

While it's possible that some users may make use of this behavior intentionally, this appears to be undefined behavior with camera smoothing.

Screen.Recording.2024-04-02.at.6.06.49.PM.mov

Steps to reproduce

  • Attach a Camera2D as a child of a moving Node2D
  • Set position_smoothing_speed to a negative value.

Minimal reproduction project (MRP)

Issue reproduction is trivial. If you absolutely need a project, you can download the 2D platformer demo from the Asset Library and follow the steps to reproduce (open the player scene and change position_smoothing_speed on the child Camera2D)

@BrixsterPlanet
Copy link
Author

While a simple fix could be to bound the minimum value to zero, I'd like to see negative values allow the camera to move ahead of its target momentum rather than lag behind it. Although this would be more difficult to implement than just setting a minimum value since it would require keeping track of its target's momentum, this is the behavior I was attempting to achieve.

@markdibarry
Copy link
Contributor

I think it'd be better to first fix this by giving it a minimum, then make an improvement ticket/proposal so we can discuss how we want it to work. We're already pretty confident this is how we don't want it to work. 😬

@ajreckof
Copy link
Member

ajreckof commented Apr 3, 2024

I agree thre should be a minium but I disagree on the negative value having any possible meaning. The value here is the speed at which the camera position go to the nodes position. obviously without any check negative value would move away from the position which leads to this strange behaviour. All of this to say I don't see how negative value would work and I don't think they should be allowed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants