-
Notifications
You must be signed in to change notification settings - Fork 450
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
FlxCamera offset is weird. No way to offset target. #1056
Comments
From the docs:
|
Yes, but that is ambiguous. It could mean either "offset the position of the deadzone", or it could mean "offset the size of the deadzone". As it is, the implementation offsets the size and not the position, but this seems strange. Why would a user not just specify their own deadzone? |
I don't see why anyone would think that offset does not offset the position... Offsetting the size, how would that even work? |
Hi, you have a demo on how offset works: http://haxeflixel.com/demos/FlxCamera/ Not sure if the behavior was changed, but if not, the offset corresponds to "lead" in that demo and works for all camera styles. If what you want is to follow a target above your "real" target, create a dummy and make your camera follow it, then update its position to be: dummy.x = realTarget.x hope it helps |
Creating a dummy just to be able to achieve something that simple seems like a hack to me. |
Yea, hacks are good solutions sometimes. Another possibility is to add "true" offset to the camera and change the current "offset" to "lead" to don't cause confusion. |
That sounds like a much better solution to me. |
The "true" offset it what I implemented for my LD game. The "lead" seems to be something different, though. The "offset" is a point you pass into the follow() method, and simply gets added to the size of the deadzone. There is separate code for "lead" in the updateFollow() method, which uses the lead property. From what I can tell, aside from "screen by screen", the only thing the follow styles change is the deadzone. Screen by screen has some extra logic for making the camera shift one screen at a time (however, this appears to be broken, too). Currently if you wish to specify your own deadzone, you have to assign a follow type, which overrides the existing deadzone, then you must set your own deadzone again. I'm wondering if it would actually be better to separate follow style from the deadzone presets. "Follow style" could refer to what the camera is trying to move toward, which currently is either the player or the discrete map division the player is on. In implementation, the follow style would define what happens when the target (or center of the target) moves beyond the deadzone. I can think of three behaviors that might be useful:-
Given these behaviors, a user could then specify their own deadzone by changing the deadzone property. The existing presets could instead be used through a makeDeadzone method or something. However, I'm wondering how useful the presets actually are. At present, they seem a little cryptic, and the precise sizes seem a bit arbitrary. It is not obvious what the use of each is, and each is unlikely to give the precise effect a user requires. Might it be more useful just to make it easier to make a custom deadzone? Instead of having many presets, for example, something as simple as providing a method to center the deadzone? In summary, I propose the following:-
|
Added target offset in FlxCamera, #1056
Whenever there are some properties that are only relevant under some configurations, enum with constructor parameters would be a more proper way. |
@kevinresol Agreed. |
Although the offending offset parameter probably shouldn't exist, anyway? |
I'm fine with removing the parameter now that we have |
FlxCamera#follow(): remove the Offset parameter, closes #1056
The offset point you can provide in FlxCamera seems rather weird. I can't at all think why it exists, as it seems only to affect the size of the deadzone.
In my ludum dare game, I needed to be able to offset the actual target position of a sprite, so for example, the target position would be somewhere above the target sprite. I couldn't find any way of doing this, so I added a targetOffset point to the class which is added to the target x and y when updating the following.
I would make this change a PR, however I wanted to check what the existing purpose of the offset point is. Is this a badly implemented attempt at offsetting the target, or does it have a legitimate purpose?
The text was updated successfully, but these errors were encountered: