Trending Society: A curated library for people building with AI.

Overview

Pixel art is the generation task most likely to come back subtly wrong: a picture of pixel art, soft-edged and anti-aliased at an arbitrary grid, rather than pixel art. Getting it right is mostly about excluding the defaults.

Layer ships two deterministic sprite-sheet utilities alongside generation. pack_sprite_sheet assembles separate frame images into one uniform-cell sheet on a transparent background, and split_sprite_sheet cuts a sheet into its cells in reading order. These are named directly rather than discovered because they are first-party tools rather than models, with no competing alternative in the catalogue.

Generation mechanics are in the layer skill. If a sibling skill named here is missing from your available skills, ask the user to install it (npx skills add layerai/skills --skill <name>); unattended, proceed from tool schemas and flag the gap.

Name the grid and the palette

Both, every time, as numbers.

Grid: "32x32 sprite", "16x16 tile". A model given no grid produces something pixel-ish at no particular resolution, which cannot be cleaned up afterwards.
Palette: a count and a family. "Limited 16-colour palette, muted earth tones" constrains the output in a way "retro colours" does not.
Era, when the user has one in mind: 8-bit NES-era flat colour, 16-bit SNES-era with shading ramps, or modern high-resolution pixel art. These look nothing alike.

Exclude the defaults, in the prompt

The defects are predictable, so name them as exclusions: no anti-aliasing, no blur, no gradients, no soft shadows, hard-edged pixels only, one pixel per cell. Where the model declares negative_prompt, put them there instead. Also state the background: "isolated on transparent background" or "flat single-colour background", since a generated backdrop has to be cut out and pixel art does not survive a sloppy cut.

Sprite sheets and walk cycles

Do not ask one generation for a sheet of frames. Models produce a grid of loosely related drawings, and the character changes between cells, which is exactly what a sheet must not do.

The working sequence:

Generate and approve one frame: the idle or contact pose, isolated on transparent.
Generate each remaining frame separately, with the approved frame attached as reference_image, and describe only what changed: "same character, same palette, same 32x32 grid, left leg forward mid-stride, right arm back."
Review the frames as a set and reroll the ones that drifted.
pack_sprite_sheet to assemble them into a uniform-cell sheet. Its input schema is the authority on the argument shape, so read it rather than assuming the parameter name.

Give every frame one delivery canvas: output_fit with canvas: "FIXED", the sprite's width and height, and anchor: "BOTTOM_CENTER", so each sprite stands on the same point of a same-sized canvas and the set shares one sprite size. pack_sprite_sheet only centres frames; it does not align ground lines, so a frame delivered without a shared canvas bobs when the sheet plays.

Every frame after the first references frame one, not the frame before it. Chaining each frame off the last one compounds drift, so by frame four the knight is a different knight.

When a trained pixel style is in play, attach it as reference_sets and omit base_model_id entirely, so the server picks a model that can apply it. Use the same set, the same weight, and the same reference frame on every frame of the cycle.

A four-frame cycle (contact, down, passing, up) reads as motion and is far more reliable than eight. Start there and add frames only if the motion needs them.

Going the other way, split_sprite_sheet cuts a user's existing sheet into individual frames, which is the way to edit one frame of a sheet without touching the others. Leave trim_transparent off for animation frames: a cycle stays registered only while every frame keeps its full cell.

High-resolution, non-pixel animation (painted or vector characters, directional cycles, Spine parts) is layer-sprite-animation.

Tiles

A pixel tile that repeats seamlessly is a tiling problem before it is a pixel problem: set tileability: true with tile_texture: "PIXEL", which joins the edges at no cost and snaps the result to its own grid and palette. Read layer-textures for scale and visible repetition, and layer-tilesets for isometric or hex tiles that snap to a map grid. Everything on this page about grid, palette, and hard edges still applies.

Worked example

"A 32x32 walk cycle for our knight sprite."

Generate the contact pose. list_base_models with filter.use_case: "text_to_image", take the first result, then prompt: "32x32 pixel art sprite of an armoured knight, side view, contact pose with left foot forward, limited 16-colour palette, 16-bit era shading, hard-edged pixels, no anti-aliasing, no blur, no gradients, isolated on transparent background."
Approve one. This frame is now the reference for everything else.
Three more runs, one per remaining frame, each attaching the approved frame as reference_image and naming only the pose change. Every run, the first included, carries the same output_fit (FIXED, 32x32, BOTTOM_CENTER).
Check the four together for drift in palette, height, and armour detail. Reroll any that moved.
pack_sprite_sheet with the four file_id values, which returns the sheet on a transparent background.

Common mistakes

Omitting the grid size, then trying to downsample a soft image into pixels.
Asking one generation for a whole sprite sheet.
Frames on differently sized canvases, so the feet jump between cells.
Forgetting the anti-aliasing and blur exclusions, which are the defaults being excluded.
Generating frames independently with no reference frame, so the character drifts.
Generating an eight-frame cycle before a four-frame one works.
Accepting a generated background instead of asking for transparent.
Packing a sheet by hand when pack_sprite_sheet produces uniform cells deterministically.

--- name: layer-pixel-art description: "Use when making pixel art with Layer: sprites, retro game characters, pixel icons, pixel tiles, or a sprite sheet and walk cycle. Also when generated pixel art comes back blurry, anti-aliased, or at the wrong grid size, and when packing separate frames into a sheet or cutting an existing sheet into frames. Keywords: pixel art, sprite, sprite sheet, spritesheet, 16-bit, 32x32, walk cycle, animation frames, palette, dithering, pack, split." license: MIT --- # Layer Pixel Art ## Overview Pixel art is the generation task most likely to come back subtly wrong: a picture _of_ pixel art, soft-edged and anti-aliased at an arbitrary grid, rather than pixel art. Getting it right is mostly about excluding the defaults. Layer ships two deterministic sprite-sheet utilities alongside generation. `pack_sprite_sheet` assembles separate frame images into one uniform-cell sheet on a transparent background, and `split_sprite_sheet` cuts a sheet into its cells in reading order. These are named directly rather than discovered because they are first-party tools rather than models, with no competing alternative in the catalogue. Generation mechanics are in the `layer` skill. If a sibling skill named here is missing from your available skills, ask the user to install it (`npx skills add layerai/skills --skill <name>`); unattended, proceed from tool schemas and flag the gap. ## Name the grid and the palette Both, every time, as numbers. - **Grid**: "32x32 sprite", "16x16 tile". A model given no grid produces something pixel-ish at no particular resolution, which cannot be cleaned up afterwards. - **Palette**: a count and a family. "Limited 16-colour palette, muted earth tones" constrains the output in a way "retro colours" does not. - **Era**, when the user has one in mind: 8-bit NES-era flat colour, 16-bit SNES-era with shading ramps, or modern high-resolution pixel art. These look nothing alike. ## Exclude the defaults, in the prompt The defects are predictable, so name them as exclusions: no anti-aliasing, no blur, no gradients, no soft shadows, hard-edged pixels only, one pixel per cell. Where the model declares `negative_prompt`, put them there instead. Also state the background: "isolated on transparent background" or "flat single-colour background", since a generated backdrop has to be cut out and pixel art does not survive a sloppy cut. ## Sprite sheets and walk cycles Do not ask one generation for a sheet of frames. Models produce a grid of loosely related drawings, and the character changes between cells, which is exactly what a sheet must not do. The working sequence: 1. Generate and approve **one** frame: the idle or contact pose, isolated on transparent. 2. Generate each remaining frame separately, with the approved frame attached as `reference_image`, and describe only what changed: "same character, same palette, same 32x32 grid, left leg forward mid-stride, right arm back." 3. Review the frames as a set and reroll the ones that drifted. 4. `pack_sprite_sheet` to assemble them into a uniform-cell sheet. Its input schema is the authority on the argument shape, so read it rather than assuming the parameter name. Give every frame one delivery canvas: `output_fit` with `canvas: "FIXED"`, the sprite's `width` and `height`, and `anchor: "BOTTOM_CENTER"`, so each sprite stands on the same point of a same-sized canvas and the set shares one sprite size. `pack_sprite_sheet` only centres frames; it does not align ground lines, so a frame delivered without a shared canvas bobs when the sheet plays. Every frame after the first references **frame one**, not the frame before it. Chaining each frame off the last one compounds drift, so by frame four the knight is a different knight. When a trained pixel style is in play, attach it as `reference_sets` and omit `base_model_id` entirely, so the server picks a model that can apply it. Use the same set, the same weight, and the same reference frame on every frame of the cycle. A four-frame cycle (contact, down, passing, up) reads as motion and is far more reliable than eight. Start there and add frames only if the motion needs them. Going the other way, `split_sprite_sheet` cuts a user's existing sheet into individual frames, which is the way to edit one frame of a sheet without touching the others. Leave `trim_transparent` off for animation frames: a cycle stays registered only while every frame keeps its full cell. High-resolution, non-pixel animation (painted or vector characters, directional cycles, Spine parts) is `layer-sprite-animation`. ## Tiles A pixel tile that repeats seamlessly is a tiling problem before it is a pixel problem: set `tileability: true` with `tile_texture: "PIXEL"`, which joins the edges at no cost and snaps the result to its own grid and palette. Read `layer-textures` for scale and visible repetition, and `layer-tilesets` for isometric or hex tiles that snap to a map grid. Everything on this page about grid, palette, and hard edges still applies. ## Worked example "A 32x32 walk cycle for our knight sprite." 1. Generate the contact pose. `list_base_models` with `filter.use_case: "text_to_image"`, take the first result, then prompt: "32x32 pixel art sprite of an armoured knight, side view, contact pose with left foot forward, limited 16-colour palette, 16-bit era shading, hard-edged pixels, no anti-aliasing, no blur, no gradients, isolated on transparent background." 2. Approve one. This frame is now the reference for everything else. 3. Three more runs, one per remaining frame, each attaching the approved frame as `reference_image` and naming only the pose change. Every run, the first included, carries the same `output_fit` (`FIXED`, 32x32, `BOTTOM_CENTER`). 4. Check the four together for drift in palette, height, and armour detail. Reroll any that moved. 5. `pack_sprite_sheet` with the four `file_id` values, which returns the sheet on a transparent background. ## Common mistakes - Omitting the grid size, then trying to downsample a soft image into pixels. - Asking one generation for a whole sprite sheet. - Frames on differently sized canvases, so the feet jump between cells. - Forgetting the anti-aliasing and blur exclusions, which are the defaults being excluded. - Generating frames independently with no reference frame, so the character drifts. - Generating an eight-frame cycle before a four-frame one works. - Accepting a generated background instead of asking for transparent. - Packing a sheet by hand when `pack_sprite_sheet` produces uniform cells deterministically.