Why AI pixel art looks bad (and what actually fixes it)

You typed a prompt and got back something recognisably your knight or your potion, and it still looked wrong. Not wrong like a bad drawing. Wrong like a photo of pixel art taken through a wet window. Here are the three tells, the one cause, and what actually fixes it.

SpriteForge, 16×16, palette-locked

… colours

across all three, from one project palette

Retro Diffusion, same prompts

… colours

across all three, nothing shared between them

A downscale filter can't add decisions the generator never made.

The three tells

1. Mixels: pixels that don't agree on a size

In real pixel art every mark sits on one grid. This is the tell you see in most AI output: outlines that wander between one and three cells thick, curves that drift half a cell, the mixels pixel artists cannot unsee. Credit where due: Retro Diffusion's dedicated 16 px mode does snap to a real grid, as the three sprites on the right show. That is the exception. Ask a general image model for pixel art and you get the wet-window look every time.

2. Colour bloat: shades nobody chose

Real pixel art works from a small palette, each colour doing a job. The three sprites on the left use 18 colours between them because they share one project palette: the heart is six colours, the key six, the chest eight, and the outline on the heart is the outline on the chest. The three on the right use the count shown above for the same prompts, with no colour shared between any two of them. Nobody chose the extras; they are what quantising a soft gradient leaves behind, and they mean the sprites will never sit together in one game.

3. Mush: edges that anti-alias themselves

Pixel art's whole visual language is decisiveness: this pixel, this colour, done. Compare the chests. The left one has a dark outline, a lit top plane and a shadowed base, three decisions you can read at 1×. The right one is a brown rectangle with texture on it, and the heart beside it has no outline at all, so on a bright background both dissolve into it. At larger sizes the same indecision shows up as anti-aliased halos, the mush the model inherited from photographs.

One cause, not three

All three tells come from the same place: the model never works in pixels. It generates a large soft image, typically 512 px or more, and a downscale-and-quantise step tries to make it retro.

Mixels are grid alignment after averaging. Colour bloat is a palette after averaging. Mush is edges after averaging. The "pixel art" part was never in the generator; it was a filter applied afterwards.

This is why prompting harder doesn't help. "16-bit style, crisp edges, limited palette" changes what the big soft image depicts, not the fact that it is about to be averaged.

What actually fixes it - the honest list

Three real options, in increasing order of automation:

• Clean it up by hand. Pull the output into Aseprite, snap it to a grid, re-quantise to a palette, redraw every edge. It works for one hero asset. At 20 to 60 minutes per sprite, a whole game makes you the pixel artist you were trying not to need.
• Hire a pixel artist. Still the gold standard for hero pieces, portraits and key art. The problem is volume on the long tail: the 40 items, 12 enemy variants and 6 terrain sets a game needs around its hero art.
• Generate under constraints instead of filtering afterwards. This is the approach SpriteForge takes: the AI places every pixel on the grid, at final resolution, from a fixed palette. There is no downscale, so there is nothing to average. The same constraint is what makes tilesets genuinely tile (you can paint with one in your browser).

Thirty seconds, and marketing images can't hide from it. If you want to try the constraint-first approach on your own prompt, your first sprite and first paintable tileset are free, in your palette, at the low resolutions this whole argument is about.

All posts · AI tileset generator · Home