A sprite can look sharp on its download page and arrive in your game with a white rectangle, fuzzy edges, or feet that move between animation frames. These symptoms often come from the export and import pipeline. Before editing the artwork, check what happened between the source image and the final screen.
This checklist uses a small test scene and works without engine-specific code. Keep the original download unchanged, make a working copy, and change one setting at a time so you can see which step fixes the problem.
1. Build a Small Test Scene First
Start with the Pixel Knight, a Treasure Chest, and a Gold Coin. Their source dimensions differ: the knight is 16×16 pixels, the chest is 12×12, and the coin is 8×9. That makes them useful for catching accidental resizing and alignment assumptions.
Put all three on a plain background. Add a horizontal guide under the knight's feet and a square inventory slot around the coin. Keep the camera still and disable decorative effects for this first pass.
Use the same number of screen pixels per source pixel for every sprite. At a scale of 4, the knight's canvas becomes 64×64 screen pixels, the chest becomes 48×48, and the coin becomes 32×36. Making all three fill a 64×64 box would change their relative scale and distort the coin if its aspect ratio were not preserved.
If you have not chosen a consistent art scale, read the tile size guide before fitting individual assets into a scene.
2. Check Whether the Background Is Actually Transparent
A checkerboard in an image editor usually represents transparency, but a checkerboard can also be painted into an image. Test the file by placing a solid-color layer underneath it, then switching that layer between white, near-black, and a bright color.
- A solid rectangle stays around the sprite: the background may be part of the image, or transparency was lost during export or import.
- A thin light fringe appears only on the dark background: inspect the edge pixels and the engine's filtering and alpha settings.
- An intentional glow or shadow blends with each background: partial transparency may be working correctly. Do not erase it just to force a hard outline.
Download the actual asset file rather than taking a screenshot of its preview. A screenshot includes the preview background. Save your working sprite in a format that preserves transparency, such as PNG, and reopen the exported file to confirm the result.
If the PNG looks correct in the editor but shows a box in the game, inspect the imported texture and the material's transparency behavior. Repeatedly removing the background from an already transparent source will not fix an import setting.
3. Separate Source Resolution from Display Scale
Keep a 16×16 sprite at 16×16 in your source files unless you deliberately need a different delivery size. Scale its display in the game. Enlarging a file first and then scaling it again makes it harder to track the relationship between artwork pixels and screen pixels.
For crisp pixel art, start with nearest-neighbor sampling, sometimes called point filtering. Compare the result at a whole-number display scale such as 2, 3, or 4. If your engine has texture size limits or automatic resizing, confirm that the imported dimensions still match the source.
Check the complete path to the screen. A sharply sampled sprite can still become blurry when a low-resolution game viewport is stretched with a smoothing filter. Camera zoom, parent transforms, viewport stretching, and display scaling all contribute to the final result.
For example, scaling a 16-pixel-wide sprite to 40 screen pixels gives a factor of 2.5. Nearest-neighbor sampling can keep the colors sharp, but some source pixels must occupy more screen pixels than others. Use a 32- or 48-pixel width for a simple comparison. A clean result there points toward the display scale rather than damaged artwork.
In Godot, the official image import documentation recommends lossless compression for pixel art and explains where texture filtering is configured. Use your engine's equivalent settings, then confirm the appearance in the running game.
4. Diagnose Motion Jitter Separately from Blur
If a sprite is sharp while stationary but shimmers when the camera moves, pause on several frames. Look at its position relative to the screen pixel grid. Fractional camera positions or transforms can make thin features alternate between screen pixels even when the texture is unchanged.
Test the camera and the object separately: first move the object with a fixed camera, then move the camera past a fixed object. This identifies which transform introduces the visible change.
For a deliberately pixel-aligned presentation, align the final rendered position to the chosen display grid. Keep that decision separate from gameplay simulation: rounding every physics position can introduce a different kind of uneven movement. Smooth subpixel motion and rigid pixel alignment involve visual tradeoffs, so test at the actual output resolution before choosing.
If an animation jumps even with both the object and camera fixed, inspect the frames instead. A moving foot anchor or inconsistent crop is a different problem from camera shimmer.
5. Keep Frame Bounds and Anchors Consistent
When you create animation frames, use the same canvas size and a consistent reference point. For a standing character, mark where the feet touch the ground. For an inventory item, use a consistent visual center within its slot.
Imagine two frames of the same character: the idle pose is narrow and the attack pose has an extended sword. Cropping each frame tightly and placing both at their image centers moves the character's body when the animation changes. Preserve the shared canvas, or keep and apply the original offsets if your atlas workflow trims empty space.
For a sprite sheet, check the frame width, frame height, starting offset, spacing, and frame order. A sheet that includes gutters needs a slicing configuration that accounts for them. Advance the animation one frame at a time and watch the ground guide, not just the weapon or face.
Treat the collision shape as its own gameplay decision. Transparent margins and a sword's reach do not automatically define the space the character's body should collide with.
6. Investigate Atlas Seams at Their Source
If a sprite gains a line in the color of a neighboring atlas entry, display the same sprite as a standalone texture. If the line disappears, inspect the atlas bounds, padding, filtering, and mipmap behavior.
Check that the region includes only the intended sprite. Atlas padding separates entries; edge extrusion repeats border pixels into that padding. These serve different purposes from adding transparent margins inside an animation frame. Use the exporter's padding and extrusion controls deliberately, then test the packed result at every zoom level your game supports.
Do not apply a universal mipmap rule to every project. A game that shrinks sprites or places them in a 3D scene has different needs from a fixed-scale 2D interface. The useful test is whether your chosen settings preserve the intended appearance across the views players can actually reach.
7. Run This Checklist on the Exported Game
Use this acceptance pass before importing the rest of your library:
- Transparency: view the sprite on light, dark, and bright backgrounds. Confirm that empty areas disappear and intended translucent details survive.
- Dimensions: compare the imported width and height with the original file. Confirm that the coin still has its original aspect ratio.
- Sharpness: compare the editor source with the running game at a known whole-number scale. Inspect both the texture and the final viewport scaling.
- Motion: move the camera and object separately. Check for shimmer, then step through animation frames to check the anchor.
- Packing: compare a standalone sprite with its atlas version, including the smallest display size used in the game.
- Delivery: repeat the checks in an exported build at the window sizes or device resolutions you support. Editor previews are only one stage of the pipeline.
Save the working import settings alongside a short note about your source size, display scale, and anchor convention. Keep this tiny scene in your project. The next time an asset looks wrong, you will have a known reference for deciding whether to fix the file, the import, or the way it reaches the screen.
