Disclosure: This draft was generated with AI and checked against the cited primary sources, with a separate AI editorial review. It was prepared for the FrameSprite team, which has a commercial interest in FrameSprite. Proposed examples are not executed tests unless explicitly identified as recorded fixture results.
HaxeFlixel may reuse cached image data when several sprites load the same graphic. Editing that shared pixel data can therefore alter more than one enemy. Request a unique graphic for an instance that owns destructive pixel edits, or keep the effect in per-sprite rendering state. See the bitmap cache API.
Key Takeaways
- Shared artwork is useful until an instance needs to mutate it.
- Decide whether damage paint belongs in source pixels or in a visual effect.
- Unique data has a memory cost and should follow the object's lifetime.
Confirm which object changed
Start with two enemies using the same source PNG. Disable tint effects, shaders and animation transitions. Change a single visible pixel on a disposable test copy, then inspect both enemies and any portrait using the same cached graphic.
Log the graphic identity or cache key alongside the sprite identity. Two different gameplay objects can still refer to one FlxGraphic. The FlxGraphic reference documents the cached graphic object; it is not a separate enemy simply because it is referenced by one.
If the change is only a color flash, prefer a visual modulation that does not destructively rewrite source pixels. The hit-flash guide distinguishes presentation effects from changed animation artwork.
Make destructive ownership explicit
The linked FlxSprite API provides the unique argument when loading a graphic. A simple static-image fragment illustrates the decision:
// HaxeFlixel 6.x API fragment; not executed here.
// true requests unique graphic data for destructive edits.
enemy.loadGraphic("assets/images/enemy.png", false, 0, 0, true);
Keep your real animated-frame parameters when applying this to a sprite sheet. The example's false value is for a single static image, not a recommended configuration for every character.
Do not assume a distinct cache key and a distinct gameplay object always imply all underlying pixel ownership is independent. Follow the API path used by your asset wrapper, and validate it with the two-instance test rather than adding random names until the symptom disappears.
Bound the memory and edit lifetime
Duplicating a large atlas for every enemy can cost more than the desired damage effect justifies. Choose among a unique small damageable region, a separate overlay and a shader or tint-based effect, depending on the appearance you need.
Keep the unmodified source available for reuse. A pooled sprite should not return with old damage paint unless that is part of its persistent state. Restoring alpha, tint and animation does not restore pixels that were destructively changed.
| Effect | Ownership question |
|---|---|
| Temporary hit flash | Can per-sprite rendering state express it? |
| Permanent scar on one enemy | Which unique pixel asset stores it? |
| Shared faction palette | Is a shared derived graphic intentional? |
| Reused enemy instance | When is its original art restored? |
The palette-variant guide covers a related shared-versus-individual art decision.
Acceptance before using a pool
Paint one enemy, destroy or recycle it according to your game's policy, and spawn another. Verify the untouched enemy and source preview remain unchanged. Confirm unique data is released when no longer needed.
Store the mutation ownership and reset rule in the animation handoff checklist. This is a source-grounded diagnostic for the linked HaxeFlixel 6.x API; no allocation measurement or runtime pixel edit was performed here.
Choose what a saved enemy appearance contains
If permanent damage paint must survive saving, record either the intended edit operations or an owned derived image through a documented persistence format. A runtime cache key alone is not a durable description of those edits. Conversely, temporary damage should not accidentally enter a shared persistent asset. Decide where the source graphic ends and per-enemy appearance begins. Test both saving a modified enemy and creating a fresh enemy from the original source so those two outcomes cannot silently share mutable state.
Sources and editorial ownership
Primary references checked on October 20, 2026:
Editorial owner: FrameSprite Workflow Team. Editorial and verification policy. Report a documentation correction.
Top comments (0)