You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Before that change, you could call FlxFilterFrames.applyToSprite() repeatedly on the same sprite, but calling it on a sprite that had a non-zero offset would lead to wrong result. After the change, non-zero offsets would work as expected, but calling it repeatedly no longer did.
I don't see a simple solution that keeps the behavior as expected in both situations. The best I can come up with is keeping a list of sprites that the frames have been applied to, but that doesn't eliminate the bug but just pushes it to a more complicated spot (namely, if you call it again after changing the graphics, but do have an offset). Perhaps the way to go is to create two methods - or an extra argument - and leave discerning the two situations to the user. But that's a more architectural choice.
The text was updated successfully, but these errors were encountered:
Code snippet reproducing the issue:
(Note: this is just https://haxeflixel.com/demos/FlxSpriteFilters/ cut down to a minimal sample for this bug)
Observed behavior:
After you click, the screen, the sprite flies off the screen.
Expected behavior:
After you click the screen, the sprite stays where it is supposed to, and an animated blur filter starts being applied to it.
Cause of problem:
This bug was introduced with this change: #2176
Before that change, you could call
FlxFilterFrames.applyToSprite()
repeatedly on the same sprite, but calling it on a sprite that had a non-zero offset would lead to wrong result. After the change, non-zero offsets would work as expected, but calling it repeatedly no longer did.I don't see a simple solution that keeps the behavior as expected in both situations. The best I can come up with is keeping a list of sprites that the frames have been applied to, but that doesn't eliminate the bug but just pushes it to a more complicated spot (namely, if you call it again after changing the graphics, but do have an offset). Perhaps the way to go is to create two methods - or an extra argument - and leave discerning the two situations to the user. But that's a more architectural choice.
The text was updated successfully, but these errors were encountered: