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.