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 offset issues #7489

Closed
williamd1k0 opened this issue Jan 10, 2017 · 4 comments
Closed

Camera2D offset issues #7489

williamd1k0 opened this issue Jan 10, 2017 · 4 comments

Comments

@williamd1k0
Copy link
Contributor

williamd1k0 commented Jan 10, 2017

Operating system or device - Godot version:
Windows 10 - Godot c798ff1

Issue description (what happened, and what was expected):
All specific offset methods do nothing.

set_offset(Vector2(10, 10)) # changes offset to Vector2(10, 10) - Ok
set_v_offset(5) # does nothing
set_h_offset(5) # does nothing
get_v_offset() # returns 0
get_h_offset() # returns 0
get_offset() # returns Vector2(10, 10) - Ok
@pwnSquirrel
Copy link
Contributor

pwnSquirrel commented Jan 10, 2017

The specific offset functions actually do something different than set/get_offset. The latter offset the displayed region relative to the camera2D's origin. The former ones however seem to relatively shift the screen around the origin of the offset camera view (which is the position of the camera2D node + the normal offset), considering screen size. They only work if the camera is in ANCHOR_MODE_DRAG_CENTER mode. So these function can move the "center" of the camera view to another point of your game window, if I read the source correctly (didn't test it, just looked at it).

It seems like that is more a problem of badly named methods and lack of documentation than a an actual bug.

Edit: For them actually having an effect you also have to set Drag Margin H/V Enabled to false. They are also being multiplied by the corresponding drag margin value. So if you set the left/right drag margin to 0.2 (default value) and use set_h_offset(1), the screen will be shifted by 1 * 0.2 * 0.5 (because it is relative to half of the screen width) screen widths. I don't know if that is intended or not.

@ghost
Copy link

ghost commented Apr 10, 2018

First of all thank you for your report and sorry for the delay.

We released Godot 3.0 in January 2018 after 18 months of work, fixing many old issues either directly, or by obsoleting/replacing the features they were referring to.

We still have hundreds of issues whose relevance/reproducibility needs to be checked against the current stable version, and that's where you can help us.
Could you check if the issue that you described initially is still relevant/reproducible in Godot 3.0 or any newer version, and comment about it here?

For bug reports, please also make sure that the issue contains detailed steps to reproduce the bug and, if possible, a zipped project that can be used to reproduce it right away. This greatly speeds up debugging and bugfixing tasks for our contributors.

Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.

Thanks in advance.

Note: This message is being copy-pasted to many "stale" issues (90+ days without activity). It might happen that it is not meaningful for this specific issue or appears oblivious of the issue's context, if so please comment to notify the Bugsquad about it.

@Piet-G
Copy link
Contributor

Piet-G commented Sep 15, 2018

Yeah these properties are just very poorly named. I already recorded these in #16863

@akien-mga
Copy link
Member

Closing as superseded by #16863.

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

No branches or pull requests

5 participants