Support rotated sprites (and rotated hit boxes) #255
Merged
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
We want to take into account not only the translation part of the global transform, but also the scaling. At the moment, rotations are still not dealt with. I am also not sure how performant the `to_scale_rotation_translation()` method is. (I think a different API could be faster, because we do not really need the decomposition.)
This is certainly more expensive than the old code, but also much more correct and future-proof: Inverting the affine transform allows to support rotated sprites as well. I also adapted the `sprite` example to demonstrate the feature. I am sure that glam offers very fast Affine3A inversion, yet I think it would be possible to speed this up in theory. Not sure that caching the inverted transform makes much sense, since many global transforms would be invalidated very often. On the other hand, we only perform a 2D hit box test, but the affine transform is 3D; one could skip computing the z coordinate AFAICS. Finally, an option for speedups would be to make the kind of test configurable; if it is known that certain sprites are never rotated (or even scaled), the computation could take a simpler path. Such configurability would also allow for a more expensive path: Testing the sprite pixmap for transparency at the pointer position would now be a low hanging fruit.
aevyrie
force-pushed
the
rotated_sprites
branch
from
78bb081 to
364fe8a
Compare
aevyrie
force-pushed
the
rotated_sprites
branch
from
364fe8a to
bde0b6f
Compare
|
Thank you!
Definitely something I would like to support. |
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 certainly more expensive than the old code, but also much more correct and future-proof: Inverting the affine transform allows to support rotated sprites as well.
I also adapted the
spriteexample to demonstrate the feature.I am sure that glam offers very fast Affine3A inversion, yet I think it would be possible to speed this up in theory. Not sure that caching the inverted transform makes much sense, since many global transforms would be invalidated very often.
On the other hand, we only perform a 2D hit box test, but the affine transform is 3D; one could skip computing the z coordinate AFAICS.
Finally, an option for speedups would be to make the kind of test configurable; if it is known that certain sprites are never rotated (or even scaled), the computation could take a simpler path. Such configurability would also allow for a more expensive path: Testing the sprite pixmap for transparency at the pointer position would now be a low hanging fruit.