← Back to Blog Tutorial

Common Sprite Sheet Mistakes and How to Fix Them

July 2026  ·  By ORH Studio  ·  6 min read

Sprite sheets look deceptively simple — a grid of frames packed into a single image. But a surprising number of issues only reveal themselves at runtime: animations that stutter, frames that bleed into each other, or characters that rotate from the wrong point. Most of these problems trace back to five recurring mistakes made during export or import.

This guide covers each mistake, why it happens, and the exact fix — whether you're working with Godot, Unity, GameMaker, or any other engine that uses sprite sheet atlases.

Inconsistent Frame Dimensions

Every frame in a sprite sheet must be exactly the same size. Engines divide the total image width and height by the frame count or cell dimensions to locate each frame. If even one frame is off by a pixel, the entire animation grid shifts and frames appear sliced or misaligned.

The Mistake
Exporting from different canvas sizes across animation states, or forgetting to check that all Aseprite layers share the same dimensions before merging.
The Fix
In Aseprite, use Canvas → Canvas Size and confirm all frames share one consistent dimension before exporting. When slicing in Sprite Slicer Pro, the live grid overlay will immediately show misalignment if your cell dimensions are wrong — adjust until every grid line falls cleanly between frames.

💡 Divide the total sprite sheet width by the number of columns. If the result isn't a whole number, your frames have inconsistent sizes or the sheet has unexpected padding.

Missing Padding Between Frames

Many sprite sheet export tools add a 1–2 pixel transparent gutter between frames to prevent a phenomenon called texture bleeding. At runtime, when the GPU applies bilinear filtering to sample a texture, it can accidentally sample pixels from the adjacent frame — resulting in a thin ghost artifact at animation edges, especially noticeable on moving sprites.

The Mistake
Entering a cell size of 32×32 when the sheet actually uses 32×32 frames with 1px padding — so the real stride is 33px per cell. The result is a gradual drift where later frames appear shifted.
The Fix
Check the asset's readme for its padding value. If undocumented, open the sheet in an image editor and measure the gap between frame edges manually. In Sprite Slicer Pro, enter the gap in the Padding X and Padding Y fields — separate from the cell width and height.

Wrong Naming Convention for Your Engine

File naming matters more than most developers expect. Godot's AnimatedSprite2D sorts frames alphabetically, so hero_walk_1.png, hero_walk_10.png, hero_walk_2.png will play in the wrong order. Unity's automatic animation import also relies on numeric suffixes to sequence frames correctly.

The Mistake
Exporting frames with non-padded numbers like frame_1.png through frame_10.png, which sort incorrectly as strings.
The Fix
Always use zero-padded numbers: frame_001.png instead of frame_1.png. Sprite Slicer Pro's Animation Rows naming mode handles this automatically, generating names like hero_idle_000.png, hero_idle_001.png with consistent padding.

Transparent Background Artifacts

Saving sprite sheets as JPEG strips transparency entirely — every pixel becomes opaque. Even with PNG, edge pixels from anti-aliasing against a colored background can create a visible "halo" around sprites at runtime, since the game engine composites them against a different background color than the one used during export.

The Mistake
Exporting to JPEG, or exporting to PNG after drawing on a non-transparent canvas — leaving opaque edge fringe around every sprite.
The Fix
Always export sprite sheets as PNG with transparency enabled. In Aseprite, check that the canvas background is transparent (checkerboard pattern, not white) before exporting. If you've inherited assets with a solid background, use Sprite Background Remover to strip it out and export a clean transparent PNG.

💡 In Aseprite: Edit → Preferences → Background — set the canvas background to transparent (checkerboard) so you can visually confirm there's no hidden opaque layer before export.

Not Accounting for Pivot Points

The pivot point is the origin around which an engine rotates and scales a sprite. In Godot, the default origin is the top-left corner of the sprite. In Unity, it defaults to the center. If you draw your character centered at frame coordinate (16, 16) but the engine pivots from (0, 0), rotation will swing wildly off-axis and position-based logic will be offset by half the frame size.

The Mistake
Not aligning the character's visual center with the engine's expected pivot point during art creation, then spending an hour adjusting offsets in engine to compensate.
The Fix
Decide on pivot placement before drawing. For Godot, center the character's feet at the frame's center-bottom point, then set offset in the AnimatedSprite2D node. For Unity, set the Pivot field in the Sprite Editor's slice settings to Bottom or Custom, matching your art layout. Consistent pivot placement across all animation states is critical for smooth transitions between clips.

🛠 Free Tools Referenced in This Guide