Beautify Decoration

beautify-decoration

A repo-specific iteration loop for visually redesigning a decoration in pixtuoid. Follow this when the user says "beautify X" or "make Y look better" — it short-circuits several rebuild traps and visual-design dead ends that aren't obvious from the codebase alone.

When to use

• Redesigning an existing decoration sprite (pantry, lounge, meeting, cubicle decor)
• Adding a new fixture (pendant lamp, water cooler, chalkboard, etc.)
• User says "items look too small / don't read like X / blend together"
• After making sprite edits and "I don't see any change"

The visual-iteration loop

1. Edit sprite OR layout
   ↓
2. cargo build --release --example snapshot
   ↓
3. ./target/release/examples/snapshot /tmp/snap.png
   ↓
4. .venv/bin/python3 scripts/crop-snapshot.py /tmp/snap.png --scale 3 -q <quadrant>
   (its QUADRANTS table is the zone map — or skip the quadrant guessing: snapshot --crop-furniture pantry|couch|vending|
   printer|meeting|sofa|chair|island|snackshelf|desk OR --crop-agent <label> renders a `CROP_WINDOW`
   already centered on the target — no Python step)
   ↓
5. Read the cropped PNG → self-critique → back to step 1
   ↓
6. When the checklist below passes, send the crop to the user with a short caption
   ↓
7. cargo build --release --workspace    ← rebuild the LIVE binary too
   ↓
8. Commit with iteration history (which designs were tried, why rejected)

The user is the final judge of "does it look like a fridge / coffee machine / etc." — send only once your own critique against the checklist below passes.

Step 7 is mandatory. cargo build --release --example snapshot does NOT rebuild the main binary. Users testing with ./target/release/pixtuoid run won't see sprite changes until the workspace is rebuilt. Forgetting this step is how "I changed the sprite but nothing happened in the live TUI" bugs get filed.

Step 8 is mandatory. Commit messages for sprite changes must include the iteration count and a one-line rationale for each rejected attempt. Future editors need to know which alternatives were explored — otherwise they'll re-try the same dead-end designs.

Sharp edges

1. The rebuild trap

• cargo build --release --workspace does not rebuild examples. Use cargo build --release --example snapshot when iterating on examples/snapshot.
• crates/pixtuoid-scene/build.rs embeds every .sprite in sprites/default/ at compile time, and a sprite edit, add or remove rebuilds it.
• If unsure, verify with: strings target/release/examples/snapshot | grep "<some unique string from your sprite>".

2. Snapshot size gates the large sprite variants

examples/snapshot defaults to its COLS×ROWS cells. Several layouts (pantry, corridor appliances) have conditional variants based on room dimensions. Corridor items (vending machine, printer) only appear when the cubicle aisle clears VENDING_MIN_AISLE_* / PRINTER_MIN_AISLE_* (layout/compute.rs). The default size clears every gate — don't shrink it while iterating.

Pantry-specific threshold: the large pantry counter needs the left column to fit PANTRY_COUNTER_LARGE_W plus margin (the pantry_counter_size pick in layout/compute.rs); below that, pantry_small.sprite is used (layout::pantry_counter_anim).

3. Resolution budget

• A terminal cell shows one pixel column and two pixel rows (half-block ▀): a 1x sprite is as many cells wide as it has pixels, and half as many tall.
• Subzones smaller than ~5 display cells wide blur into pixel noise — users can't read them.
• Sub-pixel detail (a 1-cell handle, a 1-cell stripe) is invisible. Iterate on silhouette + color identity, not pixel polish.
• Budget subzones against the sprite's width in cells: the pantry's 32-wide counter read at three zones (8/10/10), not six. Drop items; don't shrink them.

4. Identity mistakes that look identical to each other

Symptoms of weak identity:

• Transparent body (.): the wall color shows through, weakening the silhouette. Use a solid fill color for appliances.
• All-dark appliances: a row of M-bodied items reads as "row of dark boxes." Give each appliance a distinct base color (e.g., w white fridge against M dark coffee machine + M dark microwave with q glass).
• Symmetric H-frame on a white box → reads as washing machine, not fridge. Use asymmetric handles (single-side handle, or center-French-door pair).
• Cyan + blue dispenser dots next to each other → reads as cyan-cyan because b is dark and gets dim. Space them out or use c + r.

5. Sprite-format pitfalls

• Every row in a .sprite file must have exactly the same number of space-separated cells. Off-by-one is the most common bug.
• Verify with: awk '/^@/{next}/^#/{next}NF{print NR": "NF}' crates/pixtuoid-scene/sprites/default/foo.sprite — all NF values must match.
• Or visualize packed rows: awk '/^@/{next}/^#/{next}NF{for(i=1;i<=NF;i++)printf "%s",$i;print " ["NF"]"}' foo.sprite.
• Reuse existing palette keys when possible; new keys go in crates/pixtuoid-scene/sprites/default/pack.toml [palette] section.
• A sprite whose header carries the provenance line (every foo@Nx.sprite, and the 1x pieces the generator owns) is drawn by scripts/gen-art.py: redraw it there and run just gen-art — just gen-art-check fails on a hand edit.