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

Camera2D changing map limits results in smooth scrolling although limit_smoothed is false #63330

Closed
IceTyp opened this issue Jul 22, 2022 · 5 comments · Fixed by #63580
Closed

Comments

@IceTyp
Copy link

IceTyp commented Jul 22, 2022

Godot version

3.5 RC7

System information

Ubuntu 22.04

Issue description

Just tried Godot 3.5 RC7.

In a game I'm working on, the camera limits are set to the tilemap limits in _ready.
Now, whenever I change scenes to such a map, I see an immediate scroll at the beginning although limit_smoothed is false.
This was not the case in RC6.

Note that I would have a similar "immediate scroll" in RC6 if I set limit_smoothed to true.

I am pretty sure that this is because of this commit. The problem should be fixed if _update_scroll is only called when limit_smoothed is true. Otherwise, update should be called.

Steps to reproduce

Set up Camera2D with limit_smoothed false and change map limits such that the camera position is updating. You will observe a smooth scroll.

Minimal reproduction project

No response

@Calinou
Copy link
Member

Calinou commented Jul 22, 2022

cc @madmiraal

@madmiraal
Copy link
Contributor

@IceTyp please provide an MRP, because this is definitely not what I see.

If I set the limits in _ready():

  • With limit_smoothed enabled I see a smooth scroll to within the new limits.
  • With limit_smoothed disabled it immediately updates to be within the new limits (no scrolling).
  • With limit_smoothed enabled a call to reset_smoothing() also immediately updates it to be within the limits (no scrolling).

@IceTyp
Copy link
Author

IceTyp commented Jul 24, 2022

After investigating, I found out that moving the camera in _ready is necessary to trigger the scroll issue. Further, smoothing_enabled needs to be true.

Here is a project where I reproduced the issue: scroll_issue.zip

In this project, limit_smoothed is disabled and smoothing_enabled is true.

In Map.gd, I cover three different behaviours (in different _ready functions).

In 1), camera limits are changed and afterwards the camera position is changed.
In RC7, this results in a scroll when starting the game. This scroll is not smooth and depends on smoothing_speed. There is no scroll in RC6.
Calling reset_smoothing after changing camera position, also results in no scroll.

In 2), the camera position is changed before changing the camera limits. There is no scroll in this case.

The mentioned issue depends on the camera position before changing the limits. In certain cases, there is no scroll. However, in the next case, I could produce a delayed scroll:

In 3), the camera position is changed such that the limits should not affect the camera.
However, there are two scrolls that are delayed by a second or so. Note that these scrolls are smooth.
In RC6, there is no scroll at all.

@madmiraal
Copy link
Contributor

Thanks for the MRP.

Scenario 1 is the correct behaviour. The camera position is changed with smoothing enabled; so it smoothly scrolls to the position, but stops when it reaches the camera limits. The stop is abrupt, because limit_smoothed is not enabled. If scrolling is not desired, reset_smoothing() can be called.

Scenario 2 is incorrect behaviour. It should behave the same as Scenario 1. The only difference is that position is changed first instead of last. This is a bug. The order in which these properties are changed should not affect the behaviour.

Scenario 3 is also a bug. Setting the camera position twice should invalidate the first setting. So, the behaviour should be the same as if setting the camera the first time hadn't happened i.e the same as Scenario 2, which in turn should be behaving the same as Scenario 1 of course.

Scenario 3 also highlights two other bugs:

  1. The scrolling from the initial position to the final position should be in one direction (unless it encounters new limits as in Scenario 1). If instead of setting the initial position in _ready(), we define it in the Inspector, we should see a smooth scroll from the initial position to the target position defined in _ready(). The limits should not affect it as it's moving away from the newly defined limits i.e. they should have been applied immediately as limit_smoothed is disabled.
  2. There should not be a delay before the scrolling starts i.e. related to [3.4] When limit smoothing and smoothing are enabled simultaneously and the Camera2D is outside of the limits, there is a one frame delay before the smoothing starts. #56913.

@madmiraal
Copy link
Contributor

Scenario 3 also highlights two other bugs:

  1. The scrolling from the initial position to the final position should be in one direction (unless it encounters new limits as in Scenario 1). If instead of setting the initial position in _ready(), we define it in the Inspector, we should see a smooth scroll from the initial position to the target position defined in _ready(). The limits should not affect it as it's moving away from the newly defined limits i.e. they should have been applied immediately as limit_smoothed is disabled.
  2. There should not be a delay before the scrolling starts i.e. related to [3.4] When limit smoothing and smoothing are enabled simultaneously and the Camera2D is outside of the limits, there is a one frame delay before the smoothing starts. #56913.

I've created #63572 to capture these issues separately as they preexist in 3.4.4 and are not specific to 3.5 RC7.

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

Successfully merging a pull request may close this issue.

3 participants