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.
Resizing a HaxeFlixel graphic and resizing its collision box are separate decisions. setGraphicSize changes scale; updateHitbox then changes collision dimensions and offset and recenters the origin. Calling it after designing a smaller collider can undo that design. These operations are documented in the FlxSprite API.
Key Takeaways
- Decide whether a resize should change gameplay collision.
- Apply custom collision dimensions after automatic hitbox updates.
- Preserve an explicit world-space foot point when appearance changes.
Record the collision requirement before resizing
A character PNG can include a weapon, a shadow and empty margins. Its full rectangle is rarely a perfect body collider. Start with the intended gameplay width, height and ground-contact point, rather than deriving collision from whichever pose happens to load first.
The FlxObject reference defines object position and hitbox dimensions. Draw that box while testing. If the visual becomes twice as wide but the gameplay box should stay narrow, preserve that deliberate difference instead of treating it as a scaling bug.
For an illustrative 64 by 96 source frame, you might display the art at half scale while keeping a separately chosen body box. Those dimensions are an example, not a tested recommendation for every character.
Order automatic and custom adjustments
A typical setup can first resize the art, then refresh automatic geometry, and finally apply the game's collision policy:
// Setup fragment for the linked HaxeFlixel 6.x API.
// Not compiled or run for this guide.
sprite.setGraphicSize(32, 0);
sprite.updateHitbox();
// Apply your chosen collision size and offset after this step.
Do not insert updateHitbox at the end of every animation change without checking what it resets. A later automatic update can overwrite the offset used to place the art around the body collider. Rotation adds another concern because origin is a visual rotation reference, not the same thing as the collision box.
Use the sprite collision timing guide when different attack frames require gameplay hit regions.
Preserve a chosen foot point
Before replacing or resizing the graphic, record the world location where the feet should touch the floor. After updating dimensions and offsets, restore that intended contact point through the object's position. Calculate it from your documented canvas and foot marker, not from an arbitrary compensation discovered by dragging the sprite.
Transparent bottom margins matter. A centered offset cannot infer which transparent rows should be ignored. Keep a consistent canvas when possible, as described in the sheet preparation guide.
| Changed value | Inspect |
|---|---|
| scale or setGraphicSize | Visual dimensions |
| updateHitbox | Automatic box, offset and origin changes |
| width/height | Gameplay collider |
| offset | Artwork relative to the box |
| origin | Visual rotation pivot |
The official HaxeFlixel cheat sheet provides surrounding setup patterns. Confirm the API against the installed haxelib version; this article does not validate legacy Flixel forks.
Acceptance with debug geometry
Compare idle, attack and crouch at the same ground marker. Walk into a wall and onto a ledge with debug collision enabled. Check that changing animation does not unexpectedly widen the body box.
Repeat with the final camera zoom, but do not use zoom as a substitute for a correct collider. Store the art scale, foot marker and collision dimensions in the handoff checklist. No collision simulation was performed here; the target project must supply the acceptance observations.
Check updates after loading another graphic
Repeat the setup after a skin or equipment change that loads another graphic. A size policy applied only in the constructor can be overwritten when a later loading path refreshes frame dimensions. Centralize the order of visual scale, automatic geometry refresh and custom collider restoration in the asset-application path. Keep the desired collider in gameplay data rather than recovering it from the previous drawable's width. That makes a cosmetic skin change less likely to alter wall clearance or platform contact unintentionally.
Sources and editorial ownership
Primary references checked on October 20, 2026:
- FlxSprite scale, offset and updateHitbox
- FlxObject collision dimensions
- Official HaxeFlixel setup examples
Editorial owner: FrameSprite Workflow Team. Editorial and verification policy. Report a documentation correction.
Top comments (0)