Godot sprite blurry when moving? Diagnose the right layer first

When a sprite appears blurry while remaining stationary, but only shimmers while in motion, the issue generally stems from different problems. Misdiagnosing both as "bad filtering" can lead to hours of needless import changes. Here is a concise diagnostic path for Godot 4 pixel art.

1. First, freeze the scene while pausing the character on a single frame and stopping the camera. Soft edges throughout indicate texture filtering, while sharp visuals at rest and unstable visuals in motion suggest fractional movement, fractional scale, or camera interpolation. A thin strip from the adjacent pose may point to sprite-sheet grid or atlas bleeding.

The entire body jumping between frames is a sign of inconsistent canvases, pivots, or foot baselines. These are four distinct layers to consider. Adjust these layers one at a time during testing.

2. To address stationary blur, set the Texture filter to Nearest Sampling for Pixel Art Sprites or Animated Sprites. In the Sprite2D or AnimatedSprite2D node, navigate to CanvasItem > Texture > Filter and choose Nearest. While this setting eliminates blending between surrounding pixels, it's crucial to apply this setting to the entire project rather than individual nodes.

Mipmaps, on the other hand, can be beneficial for sprites displayed at native size or enlarged to integer values. Test the real camera scale to determine if resizing sprites below one source pixel per screen pixel contributes to shimmering.

3. If the sprite appears sharp while stationary but shimmering in motion, inspect the motion. Log the final rendered positions of both the character and Camera2D. Test four scenarios: (1) Character still, camera still; (2) Character moving, camera still; (3) Character still, camera moving; (4) Character and camera moving together.

If issues arise in cases 3 and 4 only, the camera path is likely the culprit. If case 2 also fails, investigate the character's transform and the relationship between physics updates and rendering. For intentionally crisp pixel art, verify the final screen position aligns with whole pixels, scale is an integer at the intended resolution, and both character and camera movements are synchronized. Ensure pixel-snap settings are consistent with the project's movement model.

4. Examine odd-sized frames and centering. A frame with an odd width or height and centered = true may place the visual center between pixels. While this doesn't necessarily mean every pixel sprite must disable centering, even-sized frames that remain on integer positions can function correctly. If an odd-sized frame deforms or shimmers, compare two tests: disabling Centered and aligning with an integer offset or keeping centering but adjusting the authored canvas so its anchor lands on a whole pixel. The goal is consistency in gameplay anchor, rather than a blanket rule.

5. For neighboring-frame bleed caused by atlas math, verify the sheet geometry: sheet width = cell width × columns + gutter × (columns - 1), and sheet height = cell height × rows + gutter × (rows - 1). Ensure that the exported pixels and slicer settings align. While adding padding in the editor may seem like a solution, it does not create missing source pixels. Depending on the filtering and compression techniques used, more isolation or alpha-aware edge dilation might be necessary.

6. Finally, separate frame jitter from transform jitter by overlaying every animation frame on a fixed canvas. Identify a shared foot baseline and pivot point. Limbs, capes, and weapons can extend beyond these anchors. If the overlay remains stable but the running game remains jittery, revisit transforms and the camera. However, if the overlay itself jumps, repackage the source frames before making any engine adjustments.