Blame for docs/ART_SPEC.md

# Art spec — draw against these numbers

Everything here is a hardware constraint, not a style preference. Art that
matches these drops straight into the pipeline; art that does not has to be
resampled, and resampling is what made the logo need 704 tiles instead of 109.

## Elya, canon — this section is normative

From `patch-and-veil-elya-design-lock.md`. Written here so it cannot drift
again: the first sprite batch drifted on all four counts below, and drift in a
character is not something a palette check or a tile count can catch.

| | |
|---|---|
| **hair** | **long uncut AUBURN-RED, past the waist.** Not brown. Not dark. |
| **dress** | **BROWN Victorian** — high collar, long sleeves, floor-length skirt |
| **NOT** | **no apron. No maid gear.** She is not a servant and is not dressed as one |
| **build** | petite adult woman, mid-twenties — **never childlike** |
| **NOT** | **no earrings, no jewellery, no lipstick, no makeup.** Image models add all four by default and every one of them has to be explicitly negated |
| **facing** | **RIGHT.** OAM's H-flip is free, but only if the source faces the way the game runs |
| **read** | **16-bit, not 8-bit.** She should fill her 32x32 cell and carry visible detail — hair mass, collar, sleeve, hem — not read as a 16x16 character scaled up |

The last one is a size statement, not a style one: a figure that occupies 13
of 32 pixels of width has three pixels of face and no room for the dress to be
a dress. Fill the cell.

`tools/mkart.py` will **not** build a sprite sheet from art that has not been
checked against this list. `art_spec_check()` is that check, expressed as
numbers, and it runs on every build against whatever is about to be baked:

| check | threshold | which drift it catches |
|---|---|---|
| width | **>= 24 of 32** | "fill the cell" — a narrow figure has no room for a face |
| fill | **>= 45%** | same, by area |
| skin | **>= 28 px** | a face needs pixels; the placeholder had 16 and had none |
| white | **<= 12 px** | **apron / maid's collar.** A wide flat white collar is maid gear by another name |
| hair | **>= dress/3** | "long uncut, past the waist" |
| facing | skin centroid right of hair centroid | **faces RIGHT** |

The white budget is there because the palette trick was not enough. The object
palette was deliberately scrubbed of apron white so a maid outfit would have
nowhere to live — and the drift came back anyway, through the *shape*, as a
broad flat collar drawn in the one white entry the collar legitimately needs.
A palette check cannot catch that. A pixel budget can.

Elya herself is hand-placed at native size in `mkart.py`, in the same idiom as
the `@` block and the nabla, because two rounds of generated art failed this
list and downscaling a 512 px render into a 32 px cell spends most of the cell
on mush. Generated art may still override her — but only if it passes the gate.
Keying on "the file exists" is how the apron got in the first time; the
filename never knew what was in the picture.

## Canvas

**256 x 224.** That is the whole NTSC screen. Design at 1x — not at 4x and
downscaled. Downscaling invents intermediate colours at every edge, and on a
4bpp target those either get quantised away (mush) or eat palette entries
(expensive). Hand-placed pixels at native size beat any downscale.

If you must work large, work at an **integer multiple** (2x = 512x448, 4x =
1024x896) with hard edges and no antialiasing, then nearest-neighbour down.

## Sprites

Object size is set **globally**, one pair for the whole screen (`OBSEL`). The
useful pair for a platformer is **16x16 and 32x32**:

| object | slot | notes |
|---|---|---|
| Elya | 32x32 | gives room for a jump pose and a foot-tap without swapping size |
| `@` block | 16x16 | |
| coin | 16x16 | |
| nabla | 16x16 or 32x32 | whichever the design needs — pick before drawing |

* **16 colours per sprite palette, entry 0 transparent — so 15 usable.**
* Sprites use palettes 8-15; backgrounds use 0-7. They are separate budgets,
  so sprite colour does not compete with the sky.
* **128 sprites on screen; 32 per scanline.** A 32x32 Elya costs four 16x16
  slots' worth of scanline budget. Not a concern for this design, but it is why
  you do not get an army of nablas.
* Horizontal and vertical flip are **free** in OAM. Draw Elya facing one way
  only; walking left costs nothing extra.

## Background

* 8x8 tiles, **4bpp, 15 colours + transparent**.
* Flat areas deduplicate to a single tile, so large fields of one colour are
  effectively free. **Texture is what costs VRAM**, not size.
* H/V flip works in the tilemap too — symmetric scenery is half price.
* The sky gradient is HDMA and costs no tiles at all. Do not draw a gradient
  into the background art; it will be generated.

## Palette discipline — the thing that actually bites

The logo taught this the hard way: **the source red was not flat** (11,610
unique colours), and every extra palette entry fragmented the background into
hundreds of near-identical tiles.

So: **use exact, repeated colour values.** If two areas are meant to be the same
red, they must be the *same* RGB triple, not two reds that look alike. In your
editor, work from a fixed swatch set and turn antialiasing OFF.

A good starting budget for a platformer scene:

| use | entries |
|---|---|
| Elya skin/hair/dress | 6-8 |
| `@` block + coin (gold ramp) | 3-4 |
| nabla | 3 |
| ground/scenery | 6-8 |
| **sky** | **0 — HDMA** |

## Animation

Frames cost VRAM linearly, so budget them:

| animation | frames | why |
|---|---|---|
| idle bob | 2 | |
| **foot tap** | **4** | the loop that runs while she waits on you |
| jump | 1 | |
| land | 1 | |
| coin spin | 4 | classic rotation reads at any size |
| block struck | 1 | squash frame |

That is ~13 sprite frames. At 32x32 4bpp a frame is 512 bytes, at 16x16 it is
128. Call it 8 KB of VRAM for everything, against 64 KB total and 5.2 KB already
spent on the logo.

## What to send me

PNG, native resolution, no antialiasing, hard edges, transparent background for
sprites (real alpha, not a magenta key). I will run it through
`tools/png2snes.py` and send back a preview of **exactly what the PPU renders**,
plus the tile count, before anything gets baked into the ROM.

## One boundary

Original art in the familiar idiom, not the familiar art. The mechanic — jump,
strike block, collectible pops out — is not protectable and never has been. The
specific Mario sprite, the coin sprite, the `?` glyph and the sounds are. That
is why the block is stamped `@`, and it is a better joke anyway.