Reflow a long sprite strip into a multi-row sheet

Start here

Split the original 192×16 strip into twelve 16×16 PNGs with the splitter. Extract its ZIP, then choose those twelve PNGs in the maker, keep order 0–11 and build a four-column grid. The result is 64×48 without scaling.

Expected result:

A three-row sheet containing all twelve decoded frames in the original sequence. The actual split-download-to-maker flow was independently checked cell by cell, including the PNG, manifest, ZIP and bounded preview.

What you need

Use assets/strip-12.png in the original CC 0 pack. Its reference frames and reflow-12.png are generated by a dependency-free Node 24 runner; the actual browser export is shown separately below.

Each tool accepts static PNGs. The splitter takes one source and at most 32 selected cells; the maker takes 1–32 PNGs. Per-file 10 MiB, combined selection and conservative geometry/memory limits apply. A narrower texture is not a promise of lower peak memory.

Download the original strip, frames and source runner

Tested with: Chrome 154/macOS actual twelve-frame Next 16.3.8 split-to-build flow, repeated under Cloudflare/workerd at the tool candidate. Node 24.22.0 references and independent Pillow 12.3.0 checks.

1. Extract the twelve complete source cells

In the splitter choose strip-12.png. Enter 16×16 cells, all margins 0 and both gaps 0. The plan has twelve columns and one row. Enable the inclusive range and enter 0–11 to make the intended selection explicit.

Frame 0 is(0,0,16,16); frame 11 is(176,0,16,16). Select Split into PNG frames, download the ZIP and keep its manifest. Extract the twelve strip-12-frame-000000.png through 000011.png files. The maker accepts PNG files, not a ZIP upload.

2. Import the actual split downloads into the maker

Choose the twelve extracted PNGs, not the pack's separate reference frames. Use Natural filename order and check 0–11 in the visible list. Choose Grid, Columns 4 and Require equal frame dimensions, then select Build sprite sheet.

Twelve frames need three rows: ceil(12/4)=3. The output is 4×16=64 by 3×16=48. Frame 8 starts the last row at(0,32); frame 11 occupies(48,32,16,16).

newX = (frameIndex mod 4) × 16
newY = floor(frameIndex / 4) × 16

Actual 64×48 PNG from the downloaded split frames. The Cloudflare replay produced these same PNG bytes; the preview was also 64×48/970 bytes.

3. Follow both manifests and compare every cell

Inspect the actual build manifest. The splitter's sourceFrameIndex identifies an old strip cell. The maker treats each extracted PNG as a separate source: each has sourceFrameIndex:0, while sourceIndex maps it to a selected PNG and frameIndex gives its new placed position. Keep the split manifest and filenames to retain the original strip identity.

Crop each new 16×16 contentRect and compare it with the corresponding decoded input PNG. Complete strip/grid buffers have different dimensions, so whole-buffer equality is not the right test. Checking only first/last cells or output dimensions can miss a swapped middle frame.

The recorded pipeline imported actual downloaded split PNGs and checked all twelve placements, pixels and stored ZIP payloads independently. There were zero differing output pixels against decoded inputs. The bounded preview matched too; it is not an engine importer test.

4. Reproduce the separate source reference

The source pack can regenerate the original strip, individual frames, reference grid and generic geometry sidecar. Inside the extracted sprite-grid directory run:

node --test fixture.test.mjs
node generate.mjs
node generate.mjs --check

These nine Node cases include the corrected stdin/aliased CLI checks and pure reference comparisons. They do not replace selecting the actual split downloads in the maker or replay the browser worker. The pack's generic sidecar is distinct from the tool's exported schema-version 2 manifest.

5. Keep layout, codec and importer limits separate

A different column count changes texture dimensions and can leave transparent trailing cells. It must keep the intended sequence and original frame dimensions. Verify the target importer's layout and size limits; this procedure does not create engine-native atlas resources or recover absent FPS, tags or pivots.

Original probes include [100,150,200,0] and partial-alpha 1,85,128. Pure reference operations preserve them. Browser decoding/encoding can normalize hidden RGB and round colors, so the actual flow compares decoded inputs with output instead of promising original-file channel identity.

Invalid grids, unequal strict inputs, animated/corrupt PNGs or budget failures produce no partial result. Cancel only the current run and retry with a valid smaller job. Splitting a small range still reserves its full parent source; no physical-mobile memory or timing guarantee follows from this example.