Open securas opened 3 years ago
The problem in that issue could have been solved simply by temporarily readjusting the camera limits
It's not that simple. What if you have limits like [-3000, 4000] and [-1000, 2000]? Each limit is different, so temporary readjusting them means you need to remember each limit and do some inconvenient maths.
The current offset behavior is fine IMO, but I agree that it could be made optional. There were a few complains about it.
Oh uau! It's been almost a year since this was posted. I had no hope that anyone would pay attention to it again. Saving the 4 limits somewhere in a variable is a trivial problem compared to the node arrangement that is required to be able to pan the camera safely using offsets, IMO. But yes... Having the option to use or not the behavior would make everyone happy.
I bring attention to this proposal because the Camera2D limits are somewhat overlooked, at least by personal experience.
Furthermore, if the limits are smaller than the viewport's resolution, the Camera2D struggles to be centered properly, instead forcing the area to be rendered all the way to the right, which does feel like unexpected behavior. This proposal would at least mitigate the issue with some manual scripting.
I agree with the idea! the camera movement with smooth activated was working very well before the change.
Reviving this old thread. I would like to give offset to the camera so that it shows a little bit ahead of the player's heading. But the fact that programmatically adjusting the offsets don't respect the limits results in camera showing undesired regions of the scene. Please make overriding camera limits optional. As it is now, limits are meaningless if you touch the offsets.
+1 to this issue, I was really confused that there's no way to make camera offset respect currently set limits (I'm limiting it with tilemap size). An option (disabled by default, if you think it should be that way) would be really nice
yep, I have the same problem but honestly I need both cases at the same time. For player look-ahead and look down in a platformer I want the offset to be limited. But for the screenshake I want it to scroll past it, so screenshake isn't lost when at the player is at the edges of the map.
So to me ideally there would be two offsets: offset
(how it works now) and a new one offset_limited
.
This also would have the benefit of not causing any regressions.
Describe the project you are working on: Platformer with Godot 3.2.1 but also applicable to more recent versions
Describe the problem or limitation you are having in your project: The behavior the camera2D was modified by godotengine/godot#30358 to allow changing the camera offset whilst disregarding the camera limits. This was implemented to allow for screen shaking to work in tight camera limits. The new behavior was not made optional, hence breaking compatibility and substantially complicating the implementation of behaviors like camera panning.
For a more specific example, consider moving a camera node using an animation player. As the animation player changes the position of the camera and the player can pan the camera with an additional offset. If the camera limits are not respected, then the camera can potentially pan away from the relevant game area. The alternative would be to place the camera within a parent node and move that with the animation player whilst implementing the pan by moving the camera node position within its parent. This also fails due to drag margins, rendering it necessary to align the camera at every frame.
In summary, the solution used for godotengine/godot#30358 aimed at solving a problem but severely complicates another. The problem in that issue could have been solved simply by temporarily readjusting the camera limits without a need to modify Godot and without the need to break retro-compatibility.
Describe the feature / enhancement and how it helps to overcome the problem or limitation: Revert to the original behavior and optionally implement the new behavior as an option selectable in the editor.
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: No need. This is a request to revert to previously existing code.
If this enhancement will not be used often, can it be worked around with a few lines of script?: No. It requires adding one or more additional nodes to a scene using a camera to enable the previous behavior or implementing a custom camera node.
Is there a reason why this should be core and not an add-on in the asset library?: The Camera2D is a central node for 2D games.