Camera Anchor fix #615
Open
Camera Anchor fix #615
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is to fix a problem that happened with the anchor system since we've had the Vector2 changes. Once an instance was converted into a Vector2 its reference was lost. ## The new approach This adds some congitive complexity that I wish could have been avoided, but I don't think there's anyway to combine Vector2's position and positionObj in a nice way. So what has been done is using a crude sort of tuple implementation and exposing the PositionObj in Vector2's implementation. Fortunately there's no real impact on the overall structure by doing thaat. Once we have a tuple in place, and being that there is only two types of data Vector2 uses, we actually have a way to sync to any of the anchorable types and update is working again. ## What's been changed I've had to change the method signature for anchor to support a crude type of overloading. It accepts a PositionObj or a Vector2. I originally tried using `OneOf` as a way to accept both and unwrap later but Haxe through compile errors about that approach. It's not exactly a perfect run time tuple. Once anchor has been called it is stored in an abstract tuple and later unwrapped to grab its position inside of update. The tuple's left contains a PositionObj so this is where we would have access to retrieving entities (like centerX and the like ). ## Possible breaks Running the tests show that nothing has actually broke, but if there is any reference in HaxePunk to the original Camera.anchorTarget it will be incompatible. So old code that utilized this element would be removed. This could be easily fixed by making anchorTarget a Vector2 again and wrapping it around the tuple.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is to fix a problem that happened with the anchor system since we've had the Vector2 changes: #596
Once an instance was converted into a Vector2 its reference was lost and the camera would not follow it.
The new approach
This adds some congitive complexity that I wish could have been avoided, but I don't think there's anyway to combine Vector2's position and positionObj in a nice way.
So what has been done is using a crude sort of tuple implementation and exposing the PositionObj in Vector2's implementation. Fortunately there's no real impact on the overall structure by doing thaat.
Once we have a tuple in place, and being that there is only two types of data Vector2 uses, we actually have a way to sync to any of the anchorable types and update is working again.
What's been changed
I've had to change the method signature for anchor to support a crude type of overloading.
It accepts a PositionObj or a Vector2. I originally tried using
OneOfas a way to accept both and unwrap later but Haxe through compile errors about that approach. It's not exactly a perfect run time tuple.Once anchor has been called it is stored in an abstract tuple and later unwrapped to grab its position inside of update. The tuple's left contains a PositionObj so this is where we would have access to retrieving entities (like centerX and the like ).
Possible breaks
Running the tests show that nothing has actually broke, but if there is any reference in HaxePunk to the original Camera.anchorTarget it will be incompatible. So old code that utilized this element would be removed.
This could be easily fixed by making anchorTarget a Vector2 again and wrapping it around the tuple.