Every pixelis a decision

Pixel art is a budget, not a filter

Pixel art is not a low-resolution version of ordinary art, and it is not a filter you apply at the end. It is a fixed budget of pixels and colours, spent deliberately. The first spending decision is the canvas itself, and it has a right answer you can compute.

You'll be able to: Choose a base resolution by computing which displays it lands on exactly, rather than by taste.

The budget, and why it is not a limitation

Your instinct about resolution is that it is a quality slider. More pixels, better image; the constraint is your hardware, and you turn it up when you can.

Pixel art inverts that. The canvas is chosen first and never changes, every pixel on it is placed by hand, and the whole craft is deciding which of them earn their place. A 320×180 canvas is 57,600 pixels for the entire screen — the game world, the character, the interface. That is roughly one-thirtieth the pixels of the window it will be displayed in, and every one of them is a decision.

This is not nostalgia and it is not a limitation being worked around. It is the constraint that makes the style legible: at this size a shape must read from its silhouette and its values, because there is no room for anything else, and that is exactly what makes a good sprite readable at a glance in a busy scene.

Choosing the canvas, by computation

The base resolution is the one decision that is genuinely expensive to change later, because every asset you draw is sized to it. It has an objective criterion: your game will be displayed on real screens, and the scaling should be by whole numbers. A 2.5× scale puts one source pixel across two and a half screen pixels, which the display resolves by making some of your pixels bigger than others — the shimmer that makes scaled pixel art look cheap.

So the question is which base resolutions divide evenly into the displays people actually own. Measuring eight common ones:

320×180 and 640×360 tie on exact fits, and 320×180 wins decisively on what happens when the fit is not exact — 26% wasted against 48%. That is the whole argument, and it is why this course uses it.

In detail, 320×180 lands exactly on every common 16:9 target:

The Steam Deck row is worth noticing rather than hiding: it is 16:10, so no 16:9 base fits it exactly and you will letterbox. Knowing that in advance is the difference between a deliberate border and a panicked rescale a week before release.

const DISPLAYS = [[1280,720], [1920,1080], [2560,1440], [3840,2160], [1280,800]];

function score(bw: number, bh: number) {
  let exact = 0, worstWaste = 0;
  for (const [dw, dh] of DISPLAYS) {
    const sx = dw / bw, sy = dh / bh;
    if (Number.isInteger(sx) && Number.isInteger(sy) && sx === sy) exact++;
    const k = Math.max(1, Math.min(Math.floor(sx), Math.floor(sy)));
    worstWaste = Math.max(worstWaste, 1 - (bw * k * bh * k) / (dw * dh));
  }
  return { exact, worstWaste };
}

The canvas, and the setting that ruins it

Three settings stand between you and crisp pixels, and every one of them defaults to wrong. The most damaging is the scaling filter, and its cost is not a matter of taste — it converts a sixteen-colour sprite into thirteen hundred colours, which you can count.

You'll be able to: Configure a pixel-perfect pipeline, and compute what the wrong scaling filter does to a sixteen-colour sprite.

The three settings

Everything in this course assumes a pipeline that preserves your pixels exactly, from the editor to the running game. Three settings control it, and each defaults against you.

Nearest-neighbour filtering. When your 320×180 image is drawn onto a 1920×1080 screen, something decides what colour each screen pixel gets. The default, bilinear filtering, blends between neighbouring source pixels. Nearest neighbour picks the single source pixel and repeats it. You want nearest, always.

A fixed base resolution with integer scaling. Set from lesson 1, enforced by the engine, so the game renders at 320×180 and is blown up by a whole number.

No smoothing anywhere else — not on import, not on the camera, not in a post-processing pass. Each is a separate place the same mistake can be made.

In Godot these are, respectively, Rendering → Textures → Default Texture Filter set to Nearest, the viewport stretch mode with integer scaling enabled, and the per-texture import settings. The godot2d course covers the details in its lesson 4.1; this lesson is about why they matter enough to check every one.

What bilinear actually costs, counted

The blur is the visible symptom, but the measurable damage is to your palette. Take a sprite drawn in the sixteen colours from lesson 9 and scale it up:

At the 6× that a 1080p screen uses, bilinear filtering has invented 1,327 colours in a sprite you drew with sixteen. Every one of them is a blend nobody chose, sitting between the ramp steps you spent lesson 8 constructing. The whole argument of unit 3 — that a palette is a small set of deliberate decisions — survives exactly as long as the pipeline does.

Nearest neighbour cannot invent a colour. That is not a quality judgement, it is a property: it only ever copies a source pixel, so the output palette is a subset of the input.

/** Nearest neighbour cannot introduce a colour. Prove it on your own art. */
function paletteOf(img: number[][][]): Set<string> {
  return new Set(img.flat().map(c => c.map(Math.round).join(",")));
}

const before = paletteOf(sprite);
const after = paletteOf(scaleNearest(sprite, 6));
console.assert(after.size <= before.size, "the scaler invented a colour");

Silhouette first

Fill any sprite with solid black and you should still know what it is. At the sizes this course works at that is not a stylistic preference — a fifth of a 16-pixel sprite's pixels are literally on its edge, so the silhouette is most of what you have got.

You'll be able to: Judge a sprite by its silhouette alone, and compute how much of a small sprite the silhouette actually is.

The test that decides whether a sprite works

Fill it with black. If you can still tell a sword from a key, a player from an enemy, the sprite works. If you cannot, no amount of shading will save it — because at the size it ships, and in the half-second a player looks at it, the silhouette is what they receive.

Professionals apply this before any colour is chosen. It is quick, it is merciless, and it catches the failure that is otherwise found late: two enemies that read as the same enemy, an item that reads as a rock, a character whose weapon disappears into their body.

Why it dominates at small sizes

There is a reason the test matters more here than in illustration, and it is arithmetic. Take a filled disc and count how many of its pixels touch the outside:

At 16 pixels — the size of a tile, an item, a small enemy — better than a fifth of the sprite is the silhouette. There is not much interior left to shade, and what there is has perhaps three ramp steps to work with. At 64 pixels the edge is 6% and the interior genuinely becomes the subject.

That ratio is the whole reason the advice differs by scale. "Focus on the silhouette" is not a rule someone invented; it is what happens to be true when a fifth of your pixels are on the boundary.

And a disc is the best case. For a given area the circle has the shortest boundary, so those percentages are the lowest any shape of that size can manage. Anything with a limb, a tail or a weapon runs higher:

The last row is the useful one. A two-pixel-wide feature is entirely silhouette — it has no interior at all — which is why a tail or a held weapon is the cheapest way to make a shape distinctive. It costs almost no pixels and every one of them changes the outline.

Designing a silhouette that differs

Since the silhouette carries identity, the useful question is not "is this a good shape" but "is this shape different enough from the others on screen". The practical moves are all about breaking the outline:

• Give each character one exaggerated feature that projects — a hat, a tail, a weapon held away from the body, ears.
• Avoid symmetry, which makes two silhouettes converge.
• Keep the outline free of the body: a sword held against the leg is invisible; the same sword held out is the whole read.

Jaggies, and why your first line looks wrong

A pixel line is not a stroke. It is a sequence of horizontal runs, and the eye reads a break in that sequence as damage — instantly, and long before it can say what is wrong. Once you can see the runs you cannot unsee them, and most of what separates a beginner's line from a professional's is this one thing.

You'll be able to: Decompose a pixel line into its horizontal runs, and name the run that breaks the sequence.

The first thing you will draw, and the first thing that will look wrong

Open Aseprite, pick the pencil, drag a diagonal across the canvas. Zoom out.

It looks wrong. Not subtly wrong — visibly, annoyingly wrong, in a way you can point at without being able to describe. Every beginner draws this line, and almost every beginner concludes their hand is unsteady, or the tool is bad, or that pixel art requires some drawing talent they were not issued.

None of that is the problem. The line is wrong for a reason that is completely mechanical, and you can be taught to see it in about five minutes.

A line is a sequence of runs

Zoom in far enough and a diagonal is not a stroke at all. It is a stack of short horizontal runs, each one row lower than the last:

That decomposition is the whole lesson. A run has a length. The line is a sequence of those lengths. And the eye — yours, your player's — is extremely good at spotting a sequence that does not hold.

A jaggy is a run whose length breaks the sequence. Four runs of 3 read as one clean edge. Runs of 3, 3, 2, 3 read as a dent, and you will see the dent before you can count anything.

The rule, stated so a machine can check it

For a straight line: every interior run must have the same length. The first and last runs are exempt, because a line has to start and stop somewhere and its ends are usually clipped short.

That is precise enough to compute, which means it is precise enough to argue with — and you should argue with it, because it is deliberately strict. It calls a steady 1, 2, 1, 2 alternation a defect, and a person would often accept that. Curves break it constantly and legitimately; lesson 5 is where the rule is relaxed for them. Here, straight lines, strict rule.

type Run = { x: number; y: number; n: number };

/** Group lit pixels into maximal horizontal runs, top row first. */
function runsOf(lit: Set<string>): Run[] {
  const cells = [...lit].map(k => k.split(",").map(Number))
    .sort((a, b) => a[1] - b[1] || a[0] - b[0]);
  const out: Run[] = [];
  let cur: Run | null = null;
  for (const [x, y] of cells) {
    if (cur && cur.y === y && x === cur.x + cur.n) cur.n++;
    else { if (cur) out.push(cur); cur = { x, y, n: 1 }; }
  }
  if (cur) out.push(cur);
  return out;
}

/** Interior runs must agree. Returns the indices that do not. */
function judge(runs: Run[]) {
  const inner = runs.slice(1, -1);
  const freq: Record<number, number> = {};
  inner.forEach(r => { freq[r.n] = (freq[r.n] ?? 0) + 1; });
  const modal = +Object.keys(freq).sort((a, b) => freq[+b] - freq[+a] || +a - +b)[0];
  return { modal, bad: runs.flatMap((r, i) =>
    i > 0 && i < runs.length - 1 && r.n !== modal ? [i] : []) };
}

Which slopes are actually clean

Here is where the folk advice goes wrong, and where computing beats remembering.

The usual guidance is to stick to "simple ratios" — 1:1, 2:1, 1:2 — and it is not quite right. Running the checker over every rise from 1 to 32, across a line 32 pixels wide, exactly ten of the thirty-two are clean:

The clean rises are 1, 2, 3, 4, 5, 8, 15, 16, 31 and 32. Note that 3 and 5 are in and 6 and 7 are out, which no rule about "simple ratios" would have predicted.

And now the part that surprised me, and which is the actually useful finding: whether a slope is clean depends on how long the line is, not only on its angle. The same checker, run over every rise at several lengths:

A short line forgives almost any angle, because it has barely any interior for a break to appear in. A long one forgives very few. This is why a beginner's small icons look fine and their long roof-lines and sword blades look broken — the skill did not change, the length did.

Curves, and the diagonal that is not isometric

A curve breaks lesson 4's rule on purpose — its runs are supposed to change. What must not change is the direction they change in. The same reasoning, applied to diagonals, explains why every isometric game you have ever played is not actually isometric.

You'll be able to: Construct an arc whose runs step out smoothly, and explain why pixel "isometric" sits at 26.57° rather than 30°.

The rule has to bend, but only one way

Lesson 4 asked every interior run to be the same length. A curve cannot possibly satisfy that: an arc is precisely a line whose slope changes, so its runs must change too. Point the lesson-4 checker at a circle and it reports carnage.

The rule bends, and it bends in exactly one direction. Along an arc from its flat top toward its equator, the runs get shorter — long and shallow at the top, down to single pixels at the side. What makes a curve read as a curve is that the sequence never turns around:

A run that drops and then climbs back is the curve's version of a jaggy, and your eye finds it in the same instant and with the same irritation.

Which circles the algorithm actually draws well

You will reach for circles constantly — heads, wheels, coins, bombs, the glow around a light. It is worth knowing in advance which radii come out clean, because the answer is not "all of them" and the failures are not where you would guess. Running the monotonicity check over the standard midpoint circle for every radius from 2 to 24, seventeen come out smooth and six do not:

Every radius up to 12 is fine. The trouble starts at 13 and is scattered unpredictably after that, which is why "draw a circle and nudge the radius until it looks right" is real advice rather than superstition — you are hunting for one of the smooth ones. If a 15-pixel circle looks subtly wrong to you, it is not your eye failing. It is lumpy, and 14 or 16 is not.

The diagonal that lied to you

Now apply the same thinking to straight lines and something falls out that most people who make isometric games do not know.

An isometric projection puts the ground axes at 30° from horizontal. To draw a 30° line in pixels you would need each run to be $1/\tan ({30}^{\circ })$ pixels long:

There is no such thing as a run of 1.7321 pixels. Any attempt to approximate it produces a sequence that never settles — runs of 2, 2, 1, 2, 2, 1, 2 — which lesson 4 already taught you to see as broken. So pixel artists do not draw 30°. They draw the nearest angle whose run length is a whole number:

The 2:1 diagonal is off by 3.43°, and that error is not a compromise anyone regretted — it is the whole reason the style looks clean. A projection with two equal axes and one different is properly called dimetric, not isometric.

/** The runs of one quadrant of an arc, from its flat top downward. */
function arcRuns(boundary: Set<string>): number[] {
  const byRow = new Map<number, Set<number>>();
  for (const k of boundary) {
    const [x, y] = k.split(",").map(Number);
    if (x >= 0 && y <= 0) {                       // top-right quadrant only
      if (!byRow.has(y)) byRow.set(y, new Set());
      byRow.get(y)!.add(x);
    }
  }
  return [...byRow.keys()].sort((a, b) => a - b).map(y => byRow.get(y)!.size);
}

/** A curve is smooth when its runs never turn around. */
const smooth = (runs: number[]) => runs.every((v, i) => i === 0 || v <= runs[i - 1]);

Anti-aliasing, and the palette it costs

Your editor has an anti-aliasing button and you must not press it. Coverage anti-aliasing spends colours, a pixel-art palette has almost none to spend, and for a 32-pixel sprite the arithmetic is about as bad as it can possibly get. Hand anti-aliasing spends one.

You'll be able to: Compute what automatic anti-aliasing costs in palette entries, and place a hand mid-tone at a run corner instead.

The button that ruins pixel art

Every drawing tool offers anti-aliasing, and at photographic resolutions it is free and correct. Here it is neither, and the reason is not aesthetic — it is a budget you can count.

Coverage anti-aliasing works out how much of each pixel the ideal geometric line passes through and inks it proportionally. A pixel the line clips at 30% gets 30% of the ink. This produces a beautifully smooth edge and an enormous number of intermediate tones, and intermediate tones are the one thing you do not have.

Counting the cost exactly

For a line of run $dx$ and rise $dy$, the coverage values repeat with a period set by the greatest common divisor. One of those values is a whole pixel rather than a part-tone, so the number of extra tones a line demands is one fewer:

That formula has a consequence worth sitting with. A sprite 32 pixels wide gives a line a run of $dx=31$ — and 31 is prime. Its only divisors are 1 and itself, so $\gcd (31,dy)=1$ for every rise, and the count is 30 no matter what angle you draw:

Read the 32px row against the 33px row. One pixel of extra width takes the best available case from 30 part-tones to 1. The sprite sizes everyone reaches for first — 16, 32, 48 — are the ones where automatic anti-aliasing is most expensive, because subtracting one from a power of two lands you on a prime surprisingly often.

And the budget those tones are spending against: this course targets a palette of 16 to 32 colours for the entire game. A single anti-aliased 32-pixel diagonal asks for 30 tones of one edge colour. There is no version of that arithmetic that works.

What hand anti-aliasing does instead

A pixel artist anti-aliases too, but spends differently. Rather than shading every pixel by coverage, you place a single mid-tone at the corner where one run steps down to the next — the inside of the staircase, and nowhere else.

Every corner reuses the same mid-tone, so a line with fifteen corners still costs one palette entry rather than 30. That is the entire technique, and it is why pixel art is built from a small ramp of deliberately chosen colours rather than from whatever the renderer produces.

Value does the work

Form is carried almost entirely by value — how light or dark a colour is — and hue is what you decorate it with afterwards. The trouble is that the lightness slider in your colour picker is not measuring what your eye measures, and across hues it is wrong by four ramp steps.

You'll be able to: Judge a ramp by measured lightness rather than by the picker's number, and explain why that number cannot be compared across hues.

Squint, and the hue disappears

Take any sprite you admire, desaturate it to greyscale, and it still reads. Take the same sprite, flatten its values so every colour has the same lightness, and it collapses into an unreadable smear no matter how carefully the hues were chosen. Form — the sense of a shape occupying space, lit from somewhere — is carried by value, and hue is what you spend afterwards on mood and material.

This is why every pixel art tutorial tells you to squint at your work. Squinting throws away high-frequency detail and most of your colour discrimination, leaving roughly the value structure. If it reads squinted, it reads.

So the practical question of this unit is: how do you build a set of values that step evenly? And the answer starts with a warning about the tool you will reach for first.

The picker's lightness number is not your eye's

Aseprite's colour picker gives you an HSL lightness slider, and it is tempting to build a ramp by moving it in equal steps. Within a single hue that is a decent approximation. Taking a blue at hue 210, saturation 60%, and stepping lightness 20 → 80% in equal increments of 15, then measuring what the eye actually receives:

Equal picker steps of 15% produce measured steps of 0.142, 0.132, 0.120 and 0.125. The largest is 1.19× the smallest — uneven, but not badly so. If you build a single-hue ramp with the lightness slider you will get something usable.

("Measured lightness" throughout this course means OKLab L, a scale built so that equal numeric differences are roughly equal perceived differences. It is what "evenly spaced" can actually mean as a number.)

Across hues, it falls apart completely

Now the failure that will wreck your first palette. Put six fully saturated hues at the same picker lightness of 50% — the slider insists these are equally light — and measure them:

Yellow measures 0.968 and blue measures 0.452, a spread of 0.516. From the table above, one step of a ramp is worth about 0.13. So yellow and blue at identical picker lightness are four full ramp steps apart in the only measurement that matters.

const toLinear = (c: number) => c <= 0.04045 ? c / 12.92 : ((c + 0.055) / 1.055) ** 2.4;

/** OKLab lightness of an sRGB colour, each channel in 0..1. */
function lightness(r: number, g: number, b: number): number {
  const R = toLinear(r), G = toLinear(g), B = toLinear(b);
  const l = Math.cbrt(0.4122214708*R + 0.5363325363*G + 0.0514459929*B);
  const m = Math.cbrt(0.2119034982*R + 0.6806995451*G + 0.1073969566*B);
  const s = Math.cbrt(0.0883024619*R + 0.2817188376*G + 0.6299787005*B);
  return 0.2104542553*l + 0.7936177850*m - 0.0040720468*s;
}

Hue shifting, and what it actually buys

Every pixel art tutorial tells you to rotate the hue toward blue in the shadows and toward gold in the lights. Almost all of them explain it wrongly. The usual reason — that it makes your steps read as more distinct — is measurable, and it is worth about two percent. The real reason is a gamut.

You'll be able to: Build a hue-shifted ramp, and compute the chroma headroom it buys over a fixed hue at identical lightness.

The advice, and the explanation that does not survive measurement

The advice is sound and universal: do not build a ramp by darkening one colour. Rotate the hue as you go — shadows cooler, toward blue and purple; highlights warmer, toward orange and gold. Ramps built this way look alive, and ramps built by dragging a lightness slider look like plastic.

The usual explanation is that hue shifting makes adjacent steps easier to tell apart, adding separation that lightness alone cannot. That is a claim about perceptual distance, and perceptual distance is a number. So here is the test: five ramps, every one with the identical lightness sequence and the identical chroma, differing only in how far the hue rotates across them.

A realistic shift of 60° buys two percent. That is not what anybody is seeing. The common explanation for the most repeated piece of advice in the subject does not survive contact with a measurement.

What is actually going on: the gamut is not a cylinder

Colour pickers draw the space as a cylinder — hue around, saturation out, lightness up — which quietly implies that any hue can be as vivid as any other at any lightness. That is false, and not by a little. Measuring the most chroma a monitor can actually display, at each lightness, for each hue:

At a lightness of 0.90 a green-cyan can hold nearly five times the chroma of that blue. The displayable space is a lumpy solid, widest in the purples low down and in the greens and yellows high up.

Now the consequence. A ramp that holds one hue is limited by its worst step — the chroma it can carry everywhere is whatever its most cramped end allows. A ramp that rotates its hue can follow the wide part of the solid as it climbs:

Every ramp there has exactly the same lightness at every step. The classic purple-to-gold shift carries 1.31× the chroma of the fixed blue — it is a richer ramp for free, because it is spending its lightness where the space is wide rather than where it is pinched.

And the last row is the honest limit of the argument. Chasing maximum chroma gives 2.87×, and gives you a ramp that goes purple to green and reads as two different objects. The classic shift is a moderate move toward the wide part, stopped well short of it so the ramp still reads as one material lit by one light.

A palette that works

A palette is not sixteen colours. It is four or five ramps that happen to total sixteen, and the single decision that makes or breaks it is one nobody mentions — whether the ramps share their lightness values or step past each other.

You'll be able to: Assemble sixteen colours as ramps whose lightness values interleave, and audit the result for collisions.

Sixteen colours is four ramps

The instinct on being handed a budget of sixteen colours is to pick sixteen colours. That produces a palette you cannot shade with. What you actually need is a handful of ramps — a material and its light and shade — and sixteen is the total, not the vocabulary. Four ramps of four steps, or five of three with one spare, is the shape to aim for.

Each ramp is built the way lesson 8 described: fixed lightness steps, hue rotating toward the wide part of the displayable space, chroma set by whichever step is most cramped.

So far this is bookkeeping. The interesting decision is what lightness values the ramps use, and it turns out to matter more than any of the colours.

The trap: four ramps that share four values

The obvious construction gives every ramp the same lightness sequence — say 0.30, 0.48, 0.66, 0.84 — so the ramps line up neatly. Audit the result and it is much worse than it looks:

Sixteen colours resolving to four distinct values is the failure. Lesson 7 established that value carries form; a palette with four values has four levels of form available no matter how many hues sit on them. Worse, the closest pair in the aligned palette is 0.0045 apart, which is two colours from different ramps at identical lightness and similar chroma — they will read as the same colour in anything smaller than a title screen.

Offsetting each ramp by a quarter of a step costs nothing, changes no hue, and takes the palette from four usable values to sixteen. The closest pair moves out by nearly thirteen times.

The palette this course uses

Four ramps, staggered, hue rotating toward the wide part of the space, built by the method above:

Sixteen distinct lightness levels, closest pair 0.0572 apart, covering 0.16 to 0.84. Note what it does not contain: no pure black, no pure white, and no single colour that is obviously "the red one". Every entry is a step of some material, which is what makes it shadeable.

/** Two things a palette must not do: collapse onto few values, and
    contain a pair nobody can tell apart. */
function audit(colours: [number, number, number][]) {
  const labs = colours.map(oklab);
  const levels = new Set(labs.map(l => l[0].toFixed(2))).size;
  let closest = Infinity;
  for (let i = 0; i < labs.length; i++)
    for (let j = i + 1; j < labs.length; j++)
      closest = Math.min(closest, deltaE(labs[i], labs[j]));
  return { levels, closest, span: [
    Math.min(...labs.map(l => l[0])), Math.max(...labs.map(l => l[0]))] };
}

Dithering, and the one that tiles

Dithering buys tone resolution you have not got palette entries for. Measured pixel by pixel it makes the image worse, and at the scale the eye actually works it makes it sixteen times better. Then there is a second criterion, which decides the matter for anything in a tileset.

You'll be able to: Compute what a Bayer matrix buys in apparent tones, and choose ordered dithering over error diffusion for anything that repeats.

Buying tones you cannot afford

You have sixteen colours and a wall that needs to fade from lit to shadowed across forty pixels. The ramp gives you four steps. Dithering is how you get more apparent tones out of the entries you already own: interleave two neighbouring colours in a fixed pattern and, from any distance at all, the eye averages them into something between.

The classic pattern is an ordered dither driven by a Bayer matrix — a small grid of thresholds, tiled across the image. Its size sets how many mixtures are available:

A 4×4 matrix turns two palette entries into seventeen apparent tones. Buying seventeen real tones would cost seventeen entries — the entire palette from lesson 9, for one gradient.

The 4×4 matrix itself, which is worth recognising because you will see it everywhere:

Dithering makes the image worse, and better

Here is the measurement that explains what dithering actually does. A gradient quantised down to two colours three ways, with the error measured per pixel and then over the neighbourhoods the eye integrates:

Read the first column and dithering is a mistake: it is a third worse than simply picking the nearest colour. Read the third and it is a different technique entirely — nearest colour is stuck at 0.2490 no matter how far back you stand, because its error is a bias, while dithering's error is spread so it cancels. At a 4×4 window ordered dithering is sixteen times more accurate than nearest.

That is the whole trade, and it is why dithering is worth doing and also why it is worth doing sparingly: you are paying in per-pixel correctness, which at 1× is visible as texture.

The criterion that actually decides it

Floyd–Steinberg wins the accuracy table at the largest window, and only just: 0.0109 against 0.0112, an edge of three percent. Nearly every general-purpose tool defaults to it anyway. For a tileset it is almost always the wrong choice, and the reason has nothing to do with accuracy.

Error diffusion carries state: each pixel's error is pushed into its neighbours, so what a pixel becomes depends on everything drawn before it. Ordered dithering is a pure function of position. Render the same 16×16 tile of flat mid-grey twice, changing only what sits to its left:

The Floyd–Steinberg tile comes out perfectly inverted. Flat mid-grey dithers to a checkerboard, and the error arriving from the left flips its phase, so every pixel lands the other way. Place that tile twice in a level and the two copies do not match; scroll past it and the pattern crawls.

Ordered dithering gives a bit-identical result wherever the tile is placed, because the threshold depends only on (x, y). That single property is why tilesets, and almost all pixel art, use ordered dithering despite losing the accuracy table.

A character that reads at 32 pixels

Pixel characters have big heads, and it is not a stylistic quirk inherited from anywhere. A face needs about five pixels of head height before it can have eyes and a mouth at all, and at 32 pixels tall that rules out every realistic proportion.

You'll be able to: Choose head proportions from the pixel budget rather than from anatomy, and verify the result at the size it ships.

Why every pixel character looks like that

Realistic human proportions are about seven and a half heads tall. Apply that to a 32-pixel sprite and the head is four pixels — two eyes and a mouth do not fit in four pixels, so the character has no face. That is the entire explanation for a convention people usually attribute to taste:

Five pixels is the working floor for a face — two for the eyes, a gap, one for a mouth — so anything below it is a head with nothing in it. The rule that falls out is arithmetic rather than art direction:

At 32 pixels you can just afford heroic proportions and nothing more realistic. At 16 pixels you are in chibi territory whether you wanted to be or not. This is why a 16-pixel character in a game you admire has a head a third of its height — the artist was not making a stylistic statement, they were fitting a face into the pixels available.

Checking it at the size it ships

The mistake that survives longest is looking at your sprite zoomed in. Aseprite opens at a comfortable working zoom, everything reads beautifully at 800%, and the sprite is illegible in the game. Three checks, all cheap:

• View it at 1×. Not 2×, not 3×. The size a player sees.
• Fill it black — lesson 3's test, which is about identity rather than legibility but catches different failures.
• Squint, or blur it. Anything that survives heavy blurring is carried by value structure rather than by detail, which is what survives motion too.

The walk cycle, and the feet that slide

A walk cycle is not judged by how it looks in the animation preview. It is judged against the speed the character actually moves, because those two numbers together decide the length of the step — and if the step is longer than the legs, the feet slide.

You'll be able to: Compute the step length a walk cycle implies from movement speed and frame timing, and tell whether the feet can reach it.

The four poses, and then the arithmetic

A walk cycle is built from four poses per step: contact, where the leading foot lands; down, the lowest point as weight transfers; passing, where the rear leg swings through; and up, the highest point of the push-off. Mirror them for the other leg and you have eight frames, which is the standard walk. A four-frame walk keeps contact and passing only, and reads as a simplification rather than as a mistake.

That much is craft. The part that is arithmetic, and that almost nobody checks until the animation is finished, is what the cycle implies about distance.

A full cycle is two steps. In the time it takes to play, the character moves speed × cycle time. Split that between two steps and you have the length of each stride — a number the animation must depict, because the planted foot has to stay planted relative to the ground:

A 32-pixel character has roughly fourteen pixels of leg. Any step longer than that cannot be reached, so the foot must slide along the ground to keep up — the skating that makes an otherwise good animation look wrong without the viewer being able to say why.

What actually fits

Working the constraint backwards, the cycle has a ceiling: cycle time ≤ 28000 / speed milliseconds for a step to stay within reach.

Read the bottom two rows carefully, because they are the honest finding: past about 150 px/s, a 32-pixel character cannot have a planted walk. There is no frame count that works. The options are to accept the slide, to animate a run rather than a walk — a run has an airborne phase, so nothing is planted and the constraint dissolves — or to make the character taller.

Frame timing against a 60 Hz tick

Aseprite lets you set a frame's duration in whole milliseconds. A 60 Hz game advances in steps of 16.667 of them. Only six whole-millisecond values under a third of a second land exactly on that grid, and they are all multiples of fifty.

You'll be able to: Choose frame durations that land exactly on the engine's physics tick, and compute the drift when they do not.

Two clocks that do not divide

Your animation has a duration per frame, set in milliseconds. Your game advances in ticks — Godot's physics step defaults to 60 per second, which is one tick every 16.667 ms. Nothing forces those to agree, and when they do not, an animation frame is held for the wrong number of ticks and the error accumulates.

Aseprite stores frame durations as whole milliseconds. So the question is which whole numbers of milliseconds are an exact number of ticks. Between 1 and 300, there are exactly six:

Every one is a multiple of 50 ms — which is to say a multiple of three ticks, because three ticks is the smallest whole number of ticks that is also a whole number of milliseconds. That is the practical rule this lesson exists to deliver: set frame durations in multiples of 50 ms and the two clocks agree forever.

What the near misses cost

The durations people reach for instead are the ones that look like round fractions of a second:

A third of a millisecond sounds like nothing. Over an eight-frame cycle at 80 ms per frame the drift is 26.7 ms — most of two ticks — and about two and a half seconds per minute of continuous animation. What you see is not a smooth error; it is a frame that is occasionally held one tick longer than its neighbours, so a walk cycle develops an intermittent limp that appears and disappears.

const TICK = 1000 / 60;

function driftOf(msPerFrame: number, frames: number) {
  const ticks = msPerFrame / TICK;
  const held = Math.round(ticks);                 // what the engine can do
  const perFrame = held * TICK - msPerFrame;      // what it costs
  return { ticks, exact: Number.isInteger(ticks), perCycle: perFrame * frames };
}

Anticipation, impact and the frames nobody sees

An attack that reads is not one with more frames. At 60 Hz a frame held for a single tick is on screen for 16.7 milliseconds, and a six-frame attack packed into a tenth of a second gives every frame exactly that — which is to say the player sees a blur and a result.

You'll be able to: Budget an attack across anticipation, impact and recovery, and compute how many refreshes each frame actually receives.

Three phases, and only one of them is the hit

A readable action has three parts, and the one everybody draws first is the least important of the three.

Anticipation is the wind-up: the character pulls back before striking. It tells the player what is about to happen, which is what makes an attack feel telegraphed rather than arbitrary — and in a game with a dodge button, it is the entire mechanism by which the player is given a chance.

Impact is one or two frames at the moment of contact, usually the most extreme drawing in the sequence, often paired with a flash and a freeze.

Recovery is the follow-through and the return to idle. Cutting it makes an attack feel like it was cancelled rather than completed.

The frames nobody sees

Here is the arithmetic that decides how many frames the sequence can usefully have. At 60 Hz the screen refreshes every 16.7 ms, so a frame's visibility is however many refreshes it survives:

A frame that gets one refresh is, for practical purposes, not seen — it contributes to a sense of motion and communicates nothing on its own. So the two one-refresh rows are the same animation as far as the player is concerned: a blur. Doubling from six frames to twelve at a fixed 200 ms bought nothing at all, because it halved the time each frame was visible.

The consequence is that frame count and duration are one decision, not two. If an attack must complete in 200 ms for the game to feel responsive, it has room for six frames at two refreshes each, and drawing twelve is wasted work that makes the result no clearer.

Tiles that tile

Nearly a quarter of a 16-pixel tile is border, and every border pixel is judged twice — once on its own and once against whatever sits next to it. Then there is the second problem, which is that a wall built from one tile announces itself, and the obvious fix does not work as well as you expect.

You'll be able to: Author a tile whose borders wrap, and compute how many variants repetition actually needs.

A quarter of the tile is seam

A tile is drawn once and placed hundreds of times, so its edges carry a requirement no other artwork has: the right-hand column must continue into the left-hand column of the copy beside it, and the same top to bottom. Get it wrong and a grid appears across your level that no amount of good interior work hides.

The proportion of a tile subject to that requirement is larger than it feels:

At the 16×16 this course targets, 23% of the tile is border, and each of those pixels is doing two jobs — reading correctly in place, and reading correctly against its neighbour. This is the same arithmetic as lesson 3's silhouette finding, and it produces the same advice in a different domain: at small sizes the edges are most of the work.

The other repetition, and why more variants disappoints

A seamless tile still repeats. Place one tile across a field and the eye finds the period immediately — not from the seams, which are now invisible, but from the content: a distinctive crack or highlight appearing on a perfect grid.

The obvious fix is more variants, and it works far less well than intuition suggests. With V equally likely variants placed at random, a cell has four neighbours, so the chance at least one of them is the identical tile is 1 − (1 − 1/V)⁴:

Four variants — already four times the work — still leave two thirds of your tiles touching a copy of themselves. Sixteen variants gets you to 23%, at sixteen times the drawing.

So variants are not the answer; they are a small part of it. What actually breaks up a tiled field is that most of the tile should be quiet, with the distinctive content moved out into sparse decoration placed on top — a crack here, a tuft there, at a density you control rather than one the grid dictates. Three or four quiet variants plus a handful of scattered details beats sixteen busy variants and costs less.

Autotiling, and why the number is 47

Godot's terrain painting hands you a tile set and expects you to fill it in. The number of tiles it wants looks arbitrary until you count what it is distinguishing — at which point 256 possibilities collapse to exactly 47, and you can say why each one exists.

You'll be able to: Derive the size of a blob terrain set from the neighbour configurations it must distinguish.

Counting what a tile has to know

A terrain tile has to look right against its surroundings, so what it needs to know is which of its neighbours are also terrain. There are eight neighbours — four edges and four corners — so there are $2^8=256$ possible surroundings.

Drawing 256 tiles would be absurd, and you do not have to, because most of those 256 are indistinguishable from each other. The reason is a small piece of geometry: a corner is only visible when both of its adjacent edges are filled. If the tile to the north is empty, it makes no difference whether the north-east diagonal is filled or not — the corner is not part of the terrain's outline there, and nothing you could draw would differ.

Collapse every configuration by that rule and count what is left:

Forty-seven is not a convention someone settled on. It is what you get, and the collapse is uneven in a way worth seeing:

Sixteen tiles do exactly one job each — those are the fully-surrounded and near-surrounded cases where every corner matters. Seven tiles each cover sixteen different situations — those are the sparse cases, where so few edges are filled that no corner can show at all. The seven doing the most work are the ones you draw first.

const N=1, NE=2, E=4, SE=8, S=16, SW=32, W=64, NW=128;

/** Clear each corner bit whose two adjacent edges are not both filled. */
function canonical(mask: number): number {
  let r = mask;
  if (!((mask & N) && (mask & E))) r &= ~NE;
  if (!((mask & E) && (mask & S))) r &= ~SE;
  if (!((mask & S) && (mask & W))) r &= ~SW;
  if (!((mask & W) && (mask & N))) r &= ~NW;
  return r;
}

const distinct = new Set<number>();
for (let m = 0; m < 256; m++) distinct.add(canonical(m));
console.log(distinct.size);        // 47

Backgrounds, layers and the depth budget

Parallax is usually explained as a scroll-speed trick, and the scroll speed is the easy half. The half that decides whether depth reads is value: each layer needs its own band of lightness, the palette has a finite range, and dividing it gives you a hard number of layers.

You'll be able to: Assign each parallax layer a lightness band, and compute how many layers a palette can actually separate.

Scroll speed is the easy half

A parallax background moves its layers at different rates — distant layers slower, near layers faster — and Godot's Parallax2D node reduces that to a scroll factor per layer. Setting those factors is five minutes of work, and doing only that produces a background that moves convincingly and still reads flat.

What makes depth read is atmospheric perspective: distant things are lower in contrast and closer in value to the sky, because there is more air between them and the viewer. In a photograph this happens for free. In a sixteen-colour palette you have to allocate it, and allocation means arithmetic.

The depth budget

Each layer needs an internal range of lightness — otherwise it is a silhouette with no form — and it needs a gap from its neighbours, or the layers merge. Those two requirements consume the palette's total lightness range, which for the palette built in lesson 9 measures 0.16 to 0.84, a span of 0.68.

Four layers is the practical answer for a palette like this one: enough internal range in each that the layer has form, enough separation that the eye assigns them to different distances. Going to six or seven means each layer has a span of 0.08 — roughly one ramp step — so it can be a shape but not a shaded shape.

This is why background art in games you admire tends to have three or four distinct planes rather than a smooth recession. It is not restraint; it is what the palette affords.

Effects, light, and the palette under a dimmer

Lighting a 2D scene is a multiplication, and multiplying a palette does not preserve the thing the palette was built for. Every separation you carefully arranged in unit 3 scales down with the light, and at a convincing night setting it is a fifth of what you designed.

You'll be able to: Compute what darkening a scene does to a palette's value separation, and budget effect frames against the refresh rate.

Effects are frames, and you already know their budget

A hit flash, a dust puff, an impact spark — these are animations, so lesson 14's arithmetic applies unchanged. At 60 Hz a frame needs about two refreshes to register as anything, which is 33 ms. A "one-frame flash" set to a single tick is 16.7 ms and reads as a glitch rather than as a hit; two ticks reads as a flash.

The one thing effects do differently is that they are usually drawn from the existing ramps rather than from new colours, because a spark in a colour that appears nowhere else on screen is the fastest way to make an image incoherent. The rule from unit 3 holds: the palette is the set of decisions, and an effect is spending them, not adding to them.

Lighting is a multiplication, and it costs you separation

Godot darkens a 2D scene with a CanvasModulate — every pixel multiplied toward black — and lights then raise regions back up. It is a clean model and it has a consequence for your palette that is easy to miss.

Take the sixteen colours from lesson 9 and apply a darkening factor. The figures below are measured from the palette's shipped hex values, which round slightly from the construction lesson 9 quotes — 8-bit rounding costs about 0.0007 of separation before the lighting touches it:

The separation scales with the light. At a factor of 0.2 — a convincing night — the closest pair is 0.0113, a fifth of what it was, and two colours have merged into the same measured level. Every distinction you spent lesson 9 arranging is compressed by exactly the amount you dimmed the scene.

This is why a palette that looks well-separated in the editor produces a night scene that reads as mud. The palette was audited at full brightness and the game never displays it that way.

Interface, type, and the art that sells it

A HUD is drawn in the same sixteen colours as everything else and read under worse conditions. Type has a hard floor set by the screen width, and the art a storefront wants is almost never an integer multiple of your canvas — which makes it the one thing in the project you draw at a different size.

You'll be able to: Size a pixel font from the characters a 320-pixel screen must fit, and identify which store images your base resolution cannot produce.

Type, sized by what has to fit

A pixel font is described by its glyph box: a 5×7 font has glyphs seven pixels tall in a box five wide, advancing six pixels including the gap. The choice looks aesthetic and is mostly determined by how many characters a line has to hold on a 320-pixel screen:

Three by five is the smallest that can hold a distinguishable alphabet — below it, letters that differ by one pixel start colliding — and eighty characters is a generous line. Five by seven is comfortable to read and still fits a fifty-character line, which is a sentence. Anything larger is a display face for titles rather than a body face for dialogue.

The practical decision is to pick the smallest face your longest necessary string fits into, and then never use a second body face. Two pixel fonts on one screen almost always read as an accident.

The HUD reads under worse conditions than anything else

Everything unit 3 established about value applies to the interface with less margin, because the interface has to be legible over whatever the game is doing underneath it. A health bar sitting on grass, stone and sky in the same level cannot rely on contrast against any one of them.

The reliable moves are the ones that do not depend on the background: a hard outline or a solid plate behind the element, values taken from the extreme ends of the palette rather than the middle, and — the one people skip — checking it against the brightest and darkest background in the game rather than against the one on screen when you drew it.

The art you cannot scale up

Everything else in the project is authored at 320×180 and blown up by a whole number. Store art is the exception, and the arithmetic says so:

Storefront images are sized by the storefront, and the sizes they ask for are chosen for layout rather than for your canvas. A 630×500 cover is not 320×180 times anything, so scaling your screenshot into it produces exactly the blurred, invented-colour result lesson 2 measured at 1,327 colours — on the single image that most determines whether anyone plays the game.

So capsule and cover art is drawn at its own size, as its own asset, using the same palette and the same discipline. It is the one place in the project where you author at a resolution the game never renders.

Where this goes next

This course has quoted a lot of numbers. Some are properties of arithmetic or of the sRGB gamut and will be true wherever you check them. Others are thresholds it chose, which sound identical in a table and are not. Here is which is which, and what the course did not cover at all.

You'll be able to: Separate the figures in this course that are measurements from the ones that are its own assumptions, and name what it did not teach you.

Which numbers are which

Everything quoted here was computed rather than remembered, and its labs recompute it at runtime so the prose cannot drift. That says nothing about whether a number is a fact about the world or a decision this course made, and the two have been sitting in the same tables.

Measurements. These follow from arithmetic or from the sRGB gamut. Check them anywhere and you will get the same answer:

• 47 distinct tiles from 256 neighbour configurations
• 320×180 landing exactly on 720p, 1080p, 1440p and 4K
• Coverage anti-aliasing needing dx/gcd(dx,dy) − 1 part-tones, and 30 of them for every slope in a 32-pixel sprite because 31 is prime
• Bilinear scaling turning 16 colours into 1,327 at 6×
• Only multiples of 50 ms landing exactly on a 60 Hz tick
• Yellow and blue at the same HSL lightness measuring 0.968 and 0.452
• A 60° hue rotation buying 2% of step separation and 1.31× the chroma
• 22% of a 16-pixel disc's pixels lying on its edge
• Four variants leaving 68% of tiles touching a twin

This course's own thresholds. These are choices. They are reasonable, they have served the work, and they are not measurements of anything:

If you disagree with one of those, you are not disagreeing with a measurement, and the labs will happily show you the consequences of a different value.

There is a third category, and it is the largest: everything about taste. Which four materials get ramps, which feature to exaggerate, how much to dither, where to spend anti-aliasing, how dark a night should be. Those appear throughout marked as the course's own reading, and they are the parts most worth disagreeing with.

What this course does not have

It has no citation gate. The eight other courses in this collection check their excerpts against a pinned source; this one cannot, because Aseprite publishes no open licence and there is nothing to pin. What stands in for it is that every figure is computed by the lesson's own lab, so prose and lab cannot drift — a discipline that caught six errors while this course was being written, including one where a tidy result turned out to be an artefact of colours pushed outside the displayable range.

That is a real gate and it is a narrower one. It proves the prose matches the computation. It cannot prove the computation was the right thing to compute, and three times during writing it was not: a circle metric that measured nothing, an error measured per pixel where the eye integrates locally, and a tiling test whose inputs produced no residual error to detect. Each looked like a working measurement and answered the wrong question.

Perceptual distance deserves the same caveat. OKLab is a model of perception, and a good one, but a ΔE of 0.057 is a number about a colour space rather than about your eye. It is used here because it is far better than the alternatives and because it can be computed — not because it is truth.

What it did not cover

An honest list, roughly in the order you will want them:

• Faces and expressions at portrait sizes, which is a different craft from 32-pixel characters and shares almost no technique with it.
• Idle, jump, hurt and death animations. The course covers a walk and an attack; a shipping character needs six or seven cycles.
• Isometric authoring beyond the projection arithmetic in lesson 5 — tile shapes, stacking order, and the depth sorting that goes with them.
• Shader work. 2D shaders are how hit flashes, dissolves and palette swaps are actually implemented at runtime, and godot2d lesson 9.4 covers them from the engine side.
• Normal maps and engine lighting. Lesson 18 treats light as a multiplication, which is the model, not the tooling.
• Level and encounter design. Making art for a level is not designing one.
• Colour-blind safe palettes. Everything in unit 3 assumes typical colour vision. A palette separated only by hue fails for roughly one man in twelve, and the fix — separating by value, which this course already argues for — is necessary but not sufficient.
• Atlasing, import pipelines and asset naming at the scale where a project has thousands of files.
• Working with an artist, which is what most shipping games do, and where the useful skill is specifying and reviewing rather than drawing.