HaxeFlixel / HaxeFlixel/flixel
FlxFilterFrames Issues
Nobody has claimed this yet.
- Dominant language
- Haxe
- Stars
- 2.2k
- Forks
- 522
- Avg merge
- 34m
- Merged PRs (30d)
- 1
Description
I find FlxFilterFrmaes to be an odd class in it's usage. It acts like a component that is added to sprites that can be easily modified or removed, but in actually it's pretending to do so and in fact getting the sprite's frames, drawing a new bitmap and replacing the frames of the target sprite with the new ones and changing the offset of the sprite to account for the newly added space. While handy for one-offs, the demo does this in a way I would never recommend, and showcases caveats from doing so (Which are now fixed via https://github.com/HaxeFlixel/flixel-demos/pull/349)
When i think of a similar util that behaves in a better way, I think of FlxTileFrames.fromBitmapAddSpacesAndBorders, which takes an asset and returns a new asset with the effect baked in, this is beneficial for many reasons, it doesn't make the effect seem "cost free", no one expects to be able to adjust the padding after it's application without generating an entirely new asset, where FlxFilterFrames obscures this, imo.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read FlxFilterFrames and FlxTileFrames.fromBitmapAddSpacesAndBorders to compare their asset and frame-handling behavior. Review the linked flixel-demos pull request for the demonstrated caveats; the issue does not define a specific replacement or completion criteria.
Written by the indexing model from the issue text.
Assessment
- Domain
- game-dev
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100