SPRITE SHEETS

One character image in, a labelled sprite sheet out

Give PX-Art a base character image, an action, a facing, a frame count and whether the action loops. You get back a trimmed sprite strip with every frame aligned to a shared scale and baseline, editable frame by frame, and exportable as a sprite sheet PNG with a manifest that names each animation row plus an Aseprite-compatible JSON, GIF and APNG.

What you provide

What happens between the request and the strip

The action pipeline is not one image call. It is a sequence built to keep a moving character recognisable as the same character:

1. Anchor the poseFor non-front facings, a locked turn image is produced first: the front base rotated to the target viewpoint as a single standing pose.
2. Composite a chroma canvasThe subject is placed on a keyed background with a fixed camera so the background can be removed cleanly later.
3. Image-to-videoA two-second clip is generated from that canvas — motion comes from a video model, not from independently sampled stills.
4. Decode every frameffmpeg extracts the full frame set, then frames are sampled according to the delivery semantics you asked for.
5. Key out and trim as a setThe chroma background is removed, then the whole sequence is cropped to the union of all frames, so translation across the animation survives instead of every frame being centred independently.
6. Assemble the stripFrames are laid into a strip with one scale and one baseline for the whole sequence.
7. Palette post-processingColours are conformed according to the game's style profile.
8. Quality gate, then storeFacing drift, inter-frame coherence and ground contact are checked before the result is saved into the actions module.

Keeping it the same character

Consistency here is three concrete mechanisms, not a prompt instruction:

The same machinery drives portraits, avatars and battle sprites — see characters and animation for the view types.

Frames, timing and loop semantics

• Looping actions are sampled over the half-open range from the first frame up to but excluding the last, so a walk cycle does not stutter on a duplicated pose at the seam.
• One-shot actions keep their true first and last frames, because the wind-up and the settle are the point.
• Playback rate is 6 to 15 fps; duration is simply frames divided by fps, so a 6-frame walk at 12 fps is half a second.
• A dense frame set is retained alongside the delivered strip, capped at 30 frames. Delete a frame you dislike and a real frame can be pulled in to replace it — one that already shares the delivered strip's scale and baseline, rather than a freshly generated stranger.

Editing what came back

The results desk is where a sheet becomes usable. You can step through frame by frame, delete frames, redo the whole run, or patch a single frame locally when one hand or one shadow is wrong. Local edits cost 2 credits per patch, which makes fixing one frame far cheaper than regenerating a 10-credit action.

Exporting

Export packs a ZIP per character containing every state you selected:

slime/
  slime-sprite-sheet.png     atlas, one row per animation
  slime-manifest.json        rows, pivots, per-frame rects
  slime-sprite-sheet.json    Aseprite-compatible frames + frameTags
  frames/walk/slime-frame-00.png ...
  gif/slime-walk.gif
  apng/slime-walk.png        full alpha, unlike GIF

The manifest is the part an engine or an agent reads:

{
  "app": "px-art",
  "schema": "perfectpixel.sprite/2",
  "version": 2,
  "character": "slime",
  "sheet": {
    "image": "slime-sprite-sheet.png",
    "width": 1536, "height": 384,
    "cellWidth": 256, "cellHeight": 256,
    "trimmed": true
  },
  "animations": {
    "walk": {
      "row": 0, "frames": 6, "fps": 12, "loop": true,
      "durationMs": 83,
      "pivot": { "x": 128, "y": 240 },
      "rects": [ { "x": 0, "y": 0, "w": 256, "h": 256 } ],
      "trims": [ { "x": 62, "y": 40, "w": 130, "h": 200 } ]
    }
  }
}

pivot is the foot anchor at the bottom centre of a cell — the value you feed to your engine so a character stands on the ground instead of floating. rects are absolute coordinates on the sheet; trims are the content bounding box inside each cell, which is what you want for tight hit boxes. The Aseprite-compatible file carries frames, frameTags and per-frame duration in milliseconds, so importers built for that format pick up the animation names without extra work.

Reading a sheet from a coding agent

Every stored strip carries its frame count and size, so an agent calling search_assets sees "kind": "action", "frames": 6 and the pixel dimensions before it downloads anything. preview_assets confirms it visually, get_asset_downloads issues a short-lived URL. Details on the MCP page.

Getting it into your game

Slice by cellWidth and cellHeight, take the animation names and fps from the manifest, and set your texture filter to nearest for pixel styles. Importers that already speak the Aseprite JSON layout can consume the second JSON file directly. There is a thin Godot-side adapter for scene bundles; Unity support is not claimed.

Limits and things to check

• Generation is probabilistic. A run can miss the description. Check before production; that is what the results desk and frame-level edits are for.
• The video stage can refuse. The pipeline depends on the model obeying the chroma-key background and fixed camera. When it does not, the run reports an error and asks for a regenerate rather than shipping broken frames.
• Mirrored facings are mirrors. Asymmetric details — a scar, a shoulder pad, a weapon in one hand — flip with the image on west, south-west and north-west.
• One frame is a still. A 1-frame action is a pose, not an animation; the loop-sampling rules only mean something from 2 frames up.
• Rights are yours to verify. Commercial use is allowed for legally generated assets, subject to third-party rights, applicable law and AI-provider terms; results are not guaranteed exclusive or registrable.
• Composition needs a desktop. Sheets can be reviewed anywhere, but the Arrange workspace expects a large canvas and precise pointer control.

An action costs 10 credits when frame-based and 18 when video-based; local frame repair is 2 credits per patch. Failed or partially failed runs refund the unfinished portion automatically. See pricing; formal checkout is still under review and not open yet.

FAQ

Related