DEV Community: FrameSprite

Stop changing your sprite sheet to fix animation speed

FrameSprite — Sat, 05 Sep 2026 03:15:50 +0000

An eight-frame animation does not have a fixed duration. At 8 fps it lasts one second; at 12 fps it lasts two-thirds of a second; at 16 fps it lasts half a second. Before drawing or generating more frames, check whether the problem is missing poses or the time each pose stays on screen.

We maintain FrameSprite, a browser workspace for game assets. This is a timing and export note, not a claim that a particular frame count makes AI animation reliable. The equations work with hand-drawn sprites too.

Three numbers that are easy to mix up

Source FPS describes how a recording was sampled. Frame count is the number of entries you put in an animation. Playback FPS controls how fast those entries advance in the game. A 24 fps source video can provide eight selected poses that you play at 12 fps. You do not need to preserve every source frame.

For equal holds, forward playback and a speed multiplier of 1:

duration_seconds = frame_count / playback_fps
frame_hold_ms = 1000 / playback_fps
fps_for_target = frame_count * 1000 / target_duration_ms

Same eight frames	Hold per frame	Full loop
8 fps	125 ms	1.000 s
12 fps	83.333… ms	0.667 s
16 fps	62.5 ms	0.500 s

You changed the cadence without changing one pixel of the sprite sheet.

A test you can reproduce

Use the public eight-frame sample. Keep the same frames, order, canvas and pivot for all three trials. Change only playback FPS between 8, 12 and 16.

Check the animation alone at its intended game size.
Run it beside actual movement or attack timing.
If cadence improves but a foot or weapon still jumps, inspect the missing phase instead of raising FPS again.
If every frame jumps by a small amount, inspect canvas and pivot alignment.
If the pause happens only at the seam, look for an accidental duplicate endpoint.

The sample makes the arithmetic test repeatable. It is not evidence that eight frames is the right budget for every character or action.

Do not accumulate rounded timestamps

At 24 fps, one hold is 41.666… milliseconds. Storing 41.67 ms and repeatedly adding it introduces rounding drift. Calculate each boundary from its index instead:

function timingRows(frameCount, fps) {
  if (!Number.isInteger(frameCount) || frameCount < 1 || frameCount > 1000) {
    throw new RangeError("Frame count must be an integer from 1 to 1000");
  }
  if (!Number.isFinite(fps) || fps < 0.01 || fps > 240) {
    throw new RangeError("FPS must be between 0.01 and 240");
  }
  return Array.from({ length: frameCount }, (_, index) => ({
    index,
    startMs: index * 1000 / fps,
    endMs: (index + 1) * 1000 / fps,
  }));
}

For 60 frames at 24 fps, the last entry is index 59. It starts at approximately 2458.333 ms and ends at 2500 ms. Round when displaying or serializing, not before calculating the next boundary.

Transfer the schedule, not an assumption

In Godot, SpriteFrames.set_animation_speed() sets animation FPS. Individual frames also have relative durations: a duration of 2 holds twice as long as 1. The simple equation above assumes all those durations are 1 and playback speed has not been changed. See the official SpriteFrames reference.

In Phaser, animation frameRate controls frame advancement; it is separate from the game's rendering frame rate. Check overrides such as extra frame duration, delays and playback speed. See the official Animation reference. Both references were rechecked on 2026-09-10.

Variable holds, ping-pong traversal, transition blending and runtime stalls need additional reasoning. A spreadsheet of equal frame holds cannot diagnose them.

A small handoff that prevents rework

When handing work to another developer, record the frame count, playback FPS, intended duration and loop setting in the asset's README or issue. For this example: “Eight frames at 12 fps, equal holds, forward loop, no duplicate endpoint; approximately 0.667 seconds per cycle.”

Correction (2026-09-10): An earlier version incorrectly stated that FrameSprite's timing calculator offered CSV export and shareable settings. It currently provides on-page timing calculations only. The equations and examples above are unchanged. This correction was prepared with AI assistance and checked against the current tool implementation and the linked engine documentation.

A Seven-Field Prompt Contract for Usable 2D Game Assets

FrameSprite — Thu, 03 Sep 2026 13:03:20 +0000

An AI image prompt becomes more useful for game development when every sentence maps to something you can inspect in the output. Instead of asking for a generic “game asset,” define seven fields: the deliverable, subject, art contract, camera, composition, background, and exclusions. Then test the result against the needs of that specific asset class.

Why “game asset” is too broad

A full-body character, inventory icon, UI panel, map, VFX sheet, and terrain tile can share a visual style, but they cannot share one output contract.

A character needs a readable silhouette, complete limbs, and room for later motion.
An icon has to survive at its smallest runtime size.
UI artwork needs complete borders and quiet areas for real text and states.
A map needs a declared camera and readable routes.
VFX needs ordered motion inside fixed cells.
A tile needs exact edges that repeat without a visible seam.

This is why adding more adjectives rarely fixes a failed asset. “Beautiful, cinematic, detailed, professional” does not tell the model which camera to use, how much empty margin to preserve, or whether opposite edges must match.

The seven-field contract

Use this order:

Field	What it controls	Example
Deliverable	The actual canvas and acceptance test	Full-body character, inventory icon, true-overhead map
Subject	Visible identity and gameplay role	Young knight, common healing potion, boss attack
Art contract	Shared visual language	Clean line art, fixed palette, cel shading, one light direction
Camera	View, facing, and perspective	Strict side view facing screen-right; 90-degree orthographic overhead
Composition	Scale, placement, and safe space	Centered, complete body, generous margin on every side
Background	How the asset will be isolated or used	Uniform solid background; naturally opaque terrain
Exclusions	Common failure modes to prevent	No text, crop, duplicate equipment, horizon, or extra character

Keep the art-contract wording stable across related assets. Change the deliverable-specific fields separately. That makes a correction diagnosable: if a map shows wall fronts, strengthen the camera block rather than rewriting the palette, materials, and layout at the same time.

Worked example: a side-facing game character

Here is a compact structure:

One full-body 2D game character: a young knight with blue-white armor, a red cape, and one sword. Clean cel-shaded fantasy art with a fixed palette and clear material separation. Strict side view facing screen-right. One centered character with complete limbs and equipment, plus generous empty margin on every side. Uniform plain background. No text, scenery, ground shadow, crop, extra character, or duplicate equipment.

Every clause is testable. You can check the sword count, facing direction, crop, margin, and background before deciding whether the image is attractive.

If the result is cropped, repair composition only: strengthen “complete limbs and equipment” and add an explicit safe-margin target. If the character turns toward the camera, repair the camera field. Keep the identity and art contract unchanged so the next attempt is still comparable.

Reuse the style, not the entire prompt

For an inventory icon, retain the palette, shading, materials, and light direction, then replace the rest of the character contract:

Inventory icon: one brass healing potion for a common item tier. [Shared art contract.] Fixed three-quarter product angle, one centered object, strong silhouette at 48 pixels, consistent light, and safe padding. Isolated background. No text, hand, scenery, border, or duplicate object.

The important test now happens at 48 pixels, not at the source-image zoom level.

For a true top-down map, the contract changes again:

2D game map: a ruined sun temple with readable routes, blocked areas, and an open playable center. [Shared art contract.] True 90-degree orthographic overhead, no horizon, no vanishing point, and no visible front faces. Naturally opaque environment. No characters, UI, labels, or perspective tilt.

The map image still does not contain collision, navigation, spawns, or editable tile metadata. Those remain engine data.

A small approval loop beats a large batch

Before generating a pack, approve one representative source master and review it at the size used in the game.

Check the deliverable-specific constraint first: facing for a character, native-size silhouette for an icon, edge continuity for a tile.
Compare palette, line treatment, light, and materials with the project's accepted art contract.
Keep the successful fields unchanged.
Rewrite only the smallest block responsible for the visible failure.
Preserve the accepted source and create runtime sizes or atlases as derivatives.

This loop does not guarantee a passing generation. Ambiguous references, complex anatomy, sampling variation, and text artifacts can still cause failures. Its value is that each retry has a reason and a measurable acceptance check.

Keep image generation inside its boundary

Generated artwork can be a source asset, but it does not replace runtime behavior:

UI art still needs real text, focus states, input behavior, and responsive layout.
Maps still need collision, navigation, triggers, and spawn data.
Tilesets still need tile IDs and terrain rules.
Character art still needs pivots, hitboxes, animation states, and import settings.

Treat those boundaries as part of the prompt review. A visually strong image can still be the wrong deliverable.

I work on FrameSprite, where we separated the Create workspace into character, prop/icon, UI, map, VFX, and tileset lanes. The deeper guide contains six copyable prompt structures and a downloadable QA checklist:

https://www.framesprite.com/guides/ai-game-art-prompt-examples

The structure is model-neutral: use it anywhere you can control a prompt, then keep the engine handoff explicit.
``

Why a 60-Frame Sprite Sheet Can Break Browser Canvas Export

FrameSprite — Thu, 03 Sep 2026 07:35:30 +0000

A 60-frame animation can contain perfectly valid PNGs and still fail when a browser combines them into one sprite sheet. The failure is often not the compressed file size. It is the decoded canvas size, the source frames held in memory, and the encoder's working allocation.

Start with the final pixel budget

For a fixed-cell sheet without margins or gutters:

sheet width = columns × cell width
sheet height = rows × cell height
pixel count = sheet width × sheet height
one RGBA buffer ≈ pixel count × 4 bytes

With 60 frames at 960×960 arranged 6×10:

Item	Value
Sheet size	5760×9600
Pixels	55,296,000
One RGBA buffer	about 210.94 MiB

That estimate covers only one uncompressed RGBA buffer. A real export can also retain decoded source images, intermediate canvases, encoder memory and the final Blob. A 10 MB PNG on disk therefore does not imply a 10 MB browser operation.

Preserve resolution by changing delivery layout

The resilient fallback is a numbered PNG sequence:

run_001.png
run_002.png
...
run_060.png

Add a small manifest with frame count and intended playback FPS. If the engine requires atlases, pack smaller pages per action or per texture budget later. The source sequence remains editable and complete.

This is better than shrinking every source frame simply to make one giant sheet encode.

Validate before allocating a canvas

Export code should check width, height and total pixel area before creating the canvas. If the request is too large, offer sequence export immediately instead of attempting an allocation that may fail or freeze the page.

When using HTMLCanvasElement.toBlob, also handle a null result. Preserve the user's frames and fall back to the sequence rather than producing an empty download.

Capacity and CORS are different failures

A large allocation is a capacity problem. A tainted canvas is an origin-security problem caused by drawing cross-origin pixels without the required CORS permission. Downscaling does not repair missing CORS headers, and changing CORS settings does not make a 55-million-pixel sheet cheap.

Report these conditions separately so users get the right recovery path.

Practical export checklist

Calculate final width, height and pixel area.
Keep full-resolution numbered frames as the production master.
Split sheets by action or engine texture-page budget.
Handle a null toBlob result.
Report CORS failures separately from capacity failures.
Verify ZIP count plus first, middle and last frame.

I work on FrameSprite, where this calculation came from a real 60-frame browser-export case. The complete 12/24/60-frame comparison and failure table are here:

https://www.framesprite.com/guides/sprite-sheet-too-large-browser-canvas?utm_source=devto&utm_medium=referral&utm_campaign=large_canvas_export_20260903

A Fixed-Cell Contract for Sprite Sheets That Do Not Jitter

FrameSprite — Thu, 03 Sep 2026 03:18:29 +0000

Generating or drawing a good sequence is only half the job. A sprite sheet stops jittering when every frame obeys the same fixed-cell contract: identical canvas size, one semantic pivot, stable baseline, explicit reading order, and preserved trim offsets. Treat those values as runtime data, not as visual cleanup.

Disclosure: I work on FrameSprite. The method below is tool-independent, and the measurements come from a public, downloadable FrameSprite test strip.

Why equal-looking frames can still jitter

A renderer places a sprite rectangle around an origin. If every frame is cropped to its visible pixels, that rectangle changes as arms, capes, wings, or weapons move. Centering each new rectangle at the same transform does not center the original character. It centers a different crop on every frame.

That creates two separate problems that are often confused:

Artwork drift: the character moves relative to the logical cell.
Runtime drift: the engine changes placement through pivots, offsets, transforms, camera motion, or texture sampling.

Filtering can soften shimmer, but it cannot repair a moving pivot. Repacking can reduce atlas size, but it cannot reconstruct discarded source offsets.

The fixed-cell contract

Write these fields down before export:

Field	Contract
Cell width and height	Identical for every frame in the action
Reading order	Explicit: row-major, column-major, or named frames
Pivot meaning	A gameplay point, such as ground contact or torso root
Pivot coordinates	Measured in the same source canvas
Baseline	Shared for grounded actions
Alpha policy	Real transparency, not a painted checkerboard
Trim metadata	Original size plus X/Y offset if cells are packed
Playback	Frame order, duration, and loop policy

The key word is semantic. “Center” is not automatically a useful pivot. A grounded walk cycle often wants bottom-center or a designed foot-contact point. A flying creature may use a torso root. An attack may keep the body root stable while the weapon extends far outside the idle silhouette.

A measured example

We measured four frames from a public 4×4 strip inside identical 360×360 cells. Their visible widths changed from 145 px to 189 px, while the lowest alpha-bound varied by only 1 px.

That result matters because it separates silhouette change from root drift:

the moving limbs legitimately change the visible width;
the outer cell remains 360×360;
the canvas center remains 180×180;
the shared bottom region stays coherent.

If those four frames were independently trimmed and re-centered, the apparent character position would move even though the original fixed-cell sequence was stable.

You can inspect the full method and download the reference measurements in the sprite pivot, anchor and origin guide.

A renderer-neutral playback model

For a fixed grid, frame selection should change only the source rectangle:

type SpriteContract = {
  cellWidth: number;
  cellHeight: number;
  columns: number;
  pivotX: number;
  pivotY: number;
};

function frameRect(index: number, c: SpriteContract) {
  const column = index % c.columns;
  const row = Math.floor(index / c.columns);

  return {
    x: column * c.cellWidth,
    y: row * c.cellHeight,
    width: c.cellWidth,
    height: c.cellHeight,
    pivotX: c.pivotX,
    pivotY: c.pivotY,
  };
}

The world transform does not move when the frame changes. Only the sampled rectangle changes.

Engine terminology differs:

Unity stores a Sprite pivot in source-texture pixels.
Phaser commonly exposes a normalized origin from 0 to 1.
Godot AnimatedSprite2D combines centered drawing with a pixel offset.

The names and units differ, but the contract is the same: convert one semantic source point into each engine’s representation without redefining it per frame.

What about trimmed atlases?

Trimming is safe when the atlas keeps enough data to reconstruct the fixed source cell:

untrimmed source width and height;
packed rectangle width and height;
trim offset X and Y;
pivot in source coordinates;
rotation flag, if packing allows rotated regions.

A normalized origin of 0.5, 0.5 is not sufficient by itself. If each trimmed rectangle has a different size, its normalized center refers to a different place in the original cell.

If the exporter drops source size and trim offsets, keep the untrimmed fixed cells instead. A larger texture is often cheaper than debugging intermittent visual drift across several engines.

A five-minute diagnostic

Use this order before changing import settings:

Freeze the character at one world position and stop the camera.
Overlay all animation frames at the same top-left coordinate.
Draw the logical cell border, pivot, and gameplay baseline.
Confirm every frame uses the same outer canvas or valid trim offsets.
Test frame swapping before testing movement.
Move the character and camera separately.
Only then inspect filtering, mipmaps, pixel snapping, and compression.

If jitter remains while both the character and camera are stationary, start with the art, cell, pivot, or atlas metadata. If it appears only during camera movement, investigate fractional transforms and pixel scaling.

Where this contract should not be over-applied

Not every opaque pixel should remain fixed. Jumps, recoil, squash and stretch, flying motion, and deliberate root translation can move the center of mass. The contract stabilizes the gameplay anchor; it does not erase intentional motion.

Likewise, one pivot cannot represent every gameplay attachment. Weapon sockets, hitboxes, effect origins, and collision shapes may need separate metadata or child transforms.

The handoff test

Give the exported sheet to a developer who did not create it. If they cannot identify the cell size, reading order, pivot meaning, loop behavior, and trim reconstruction without asking the artist, the asset package is incomplete.

For a visual overlay workflow, failure table, and downloadable alignment strip, see How to fix sprite animation jitter and pivot drift. You can also test an existing sheet in FrameSprite’s free browser sprite-sheet tools; those tools run without generation credits.

A stable sprite animation is not defined by how tightly each drawing is cropped. It is defined by whether every frame can be placed from the same contract.

Stop Choosing Sprite Animation Frames by FPS

FrameSprite — Wed, 02 Sep 2026 01:44:24 +0000

If you are deciding how many frames a sprite animation needs, do not start from the source video's frame rate. Start from the poses the player must read.

Frame count and playback FPS answer different questions:

Frame count controls pose coverage.
Playback FPS controls how quickly those poses advance.

An eight-frame attack at 8 fps lasts one second. The same eight poses at 16 fps last half a second. Adding another eight near-duplicate images does not automatically improve the attack; it mostly increases the sheet, review work and opportunities for character drift.

Name the phases before drawing or generating frames

Write the action as a short sequence of readable states. An attack normally needs:

anticipation,
strike,
impact,
recovery.

A walk normally needs contact, down, passing and up. A death action needs loss of balance, the fall and a stable final pose. These are not rigid animation laws. They are a practical test: if two neighboring frames communicate the same phase with the same silhouette, one may not be earning its place.

Use a small first-pass budget

For a first playable pass, I use these ranges:

Action	Start with	What earns another frame
Idle	4–6	Breathing, cloth or equipment pops
Walk	6–8	A foot teleports or the passing pose disappears
Run	6–8	Flight time or secondary motion collapses
Attack	8–12	Weapon path, impact or recovery lacks a phase
Cast	8–12	Hands, prop or effect skip a necessary state
Hit	3–6	Contact or recoil cannot be read
Death	8–12	The fall teleports or never settles cleanly

These are starting budgets for unique poses. A hand-drawn boss with broad arcs may need more. Deliberately stepped pixel art may need fewer.

Tune time separately

Duration is simple:

duration in seconds = unique frames / playback FPS

Eight unique frames at 12 fps last about 0.667 seconds. If the animation already contains every important pose but feels floaty, increase playback FPS before adding images. If it moves at the right speed but the foot jumps from behind the body to the front, add the missing passing pose.

This separation also makes engine debugging easier. A wrong duration is a timing problem. A missing silhouette is a pose problem. A character that shifts around the canvas is an anchor or pivot problem. A sword striking behind a right-facing character is a direction or clip-selection problem. More frames do not solve the last three.

Test at game scale

A full-resolution preview can hide a weak silhouette. Preview the loop at the actual on-screen size and next to gameplay velocity, hit timing and state transitions.

For each pass, ask:

Can I name the phase represented by every frame?
Does the center of mass move continuously?
Do feet and weapons keep believable contact points?
Does the last unique frame return cleanly to the first?
Does raising FPS fix the problem without adding poses?

Only add a frame when the answer points to a missing visual state.

We published the complete seven-action matrix as downloadable CSV and JSON, with its method and limitations, in the FrameSprite frame-count guide. It is useful as a production checklist even if you draw every frame by hand and never use a generation tool.``

Godot sprite blurry when moving? Diagnose the right layer first

FrameSprite — Tue, 01 Sep 2026 11:03:37 +0000

A sprite that is blurry while standing still and a sprite that only shimmers while moving are usually suffering from different bugs. Treating both as “bad filtering” leads to hours of random import changes.

Here is the shortest diagnostic path I use for Godot 4 pixel art.

1. Freeze the scene before touching import settings

Pause the character on a single frame and stop the camera.

Soft edges while everything is still usually indicate texture filtering.
Sharp while still, unstable while moving usually indicate fractional movement, fractional scale, or camera interpolation.
A thin strip from the neighboring pose indicates sprite-sheet grid or atlas bleeding.
The whole body jumps between frames indicates inconsistent canvases, pivots, or foot baselines.

Those are four different layers. Change one at a time.

2. Fix stationary blur with Nearest filtering

For pixel art, select the Sprite2D or AnimatedSprite2D node and set:

CanvasItem → Texture → Filter → Nearest

Nearest sampling chooses the closest source pixel rather than blending surrounding pixels. If every pixel-art asset in the project needs the same policy, set the project default instead of editing every node.

Do not assume mipmaps are always wrong. A sprite displayed at native size or an integer enlargement usually does not need them. If the camera shrinks sprites below one source pixel per screen pixel, mipmaps can reduce distant shimmer. Test the real camera scale.

Godot reference: CanvasItem texture filtering

3. If it is sharp while still, inspect motion

Nearest filtering cannot repair fractional transforms.

Log the final rendered position of both the character and Camera2D. Then test four cases:

Character still, camera still
Character moving, camera still
Character still, camera moving
Character and camera moving together

If only cases 3 and 4 fail, the camera path is the likely source. If case 2 fails as well, inspect the character transform and the relationship between physics updates and rendering.

For deliberately crisp pixel art, verify:

the final screen position lands on whole pixels;
scale is an integer at the intended resolution;
character and camera are not being rounded independently in opposing directions;
physics-step movement and render interpolation are not fighting each other;
the pixel-snap settings match the project's movement model.

Godot's own guide separates jitter and stutter from texture filtering: Fixing jitter, stutter and input lag.

4. Check odd-sized frames and centering

An odd-width or odd-height frame with centered = true can place the visual center between pixels.

That does not mean every pixel sprite must disable centering. Even-sized frames that stay on integer positions can work correctly. But if an odd-sized frame deforms or shimmers, compare these two tests:

disable Centered and align with an integer offset;
keep centering, but adjust the authored canvas so its anchor lands on a whole pixel.

The goal is a consistent gameplay anchor, not a universal checkbox rule.

5. Diagnose neighboring-frame bleed as atlas math

If the wrong color appears only at a cell boundary, verify the sheet geometry:

sheet width = cell width × columns + gutter × (columns - 1)
sheet height = cell height × rows + gutter × (rows - 1)

The exported pixels and the slicer settings must agree. Adding “padding” only in the editor does not create missing source pixels.

For nearest-filtered, non-mipmapped pixel art, a real 1 px transparent gutter is a reasonable test starting point. Bilinear filtering, downscaling, compression, and mipmaps may require more isolation or alpha-aware edge dilation.

6. Separate frame jitter from transform jitter

Overlay every animation frame on one fixed canvas. Mark one shared foot baseline and one pivot.

Limbs, capes, and weapons can extend. The gameplay anchor should not wander unless the action intentionally translates the character. Cropping each frame to its opaque bounds and then centering it independently is a common way to create apparent bouncing.

If the overlay is stable but the running game is not, return to transforms and the camera. If the overlay itself jumps, repack the source frames before changing engine settings.

A compact symptom table

What you see	First place to inspect	Likely fix
Soft while still	Texture filter	Use Nearest for pixel art
Sharp still, shimmers in motion	Transform/camera	Test integer placement and update timing
Neighboring pose at cell edge	Sheet grid/gutters	Correct cell math and export real spacing
Character bounces each frame	Canvas/pivot	Normalize canvas, baseline, and pivot

The important principle is simple: filtering, motion, atlas sampling, and frame alignment are separate systems. Classify the symptom first, then change only the matching layer.

I maintain FrameSprite, and we turned this into a more detailed, engine-focused checklist with failure cases and related sprite-sheet tests:

Godot sprite blurry when moving? Fix blur and jitter

If you are debugging one of these cases now, post which of the four motion tests fails. That usually narrows the problem faster than another round of import changes.

I tested 0, 1, 2 and 4 pixel sprite-sheet gutters instead of guessing

FrameSprite — Mon, 31 Aug 2026 07:36:21 +0000

Sprite-sheet advice often collapses to one number: “add two pixels of padding.” That is easy to repeat and hard to evaluate. Padding only works in relation to the sampler, output scale, mipmap path and atlas geometry.

I wanted a smaller question that could be reproduced: when two different sprite cells touch, how much does nearest or bilinear sampling let the right cell influence the left one?

The test

The test starts with the first two cells from a public FrameSprite bone-dragon sheet. Each character image is alpha-trimmed, placed in an equal-sized cell and edge-aligned. The pair is then repacked with 0, 1, 2 or 4 fully transparent pixels between cells.

For each gutter, the script samples at 100%, 50% and 25% using nearest and bilinear filtering. The final sample is positioned a quarter source pixel inside the left cell boundary. A same-neighbor control supplies the baseline. If replacing the neighbor with a different frame changes a sampled RGBA channel by more than eight, that pixel is counted as contaminated.

What the controlled test found

Gutter	Nearest	Bilinear
0 px	No measured contamination	156 / 78 / 40 affected rows at 100% / 50% / 25%
1 px	No measured contamination	No measured contamination
2 px	No measured contamination	No measured contamination
4 px	No measured contamination	No measured contamination

One pixel separated the two bilinear taps used here. It would be tempting to stop at “one pixel is enough,” but that conclusion would exceed the experiment. The script did not generate mipmaps, apply texture compression, use repeating wrap modes or send the sheet through Unity's or Godot's atlas packer. Each of those can change how far a sample reaches or how edge colors are reconstructed.

A more useful rule than one universal number

Export real transparent space. An editor spacing field cannot create pixels that are absent from the PNG.
Keep logical frame size separate from gutter size.
Enter the exact exported spacing in the engine slicer.
Test the target filter, smallest display scale and platform build.
For bilinear filtering or mipmaps, test a larger gutter and alpha-aware edge dilation.

Edge dilation matters because a fully transparent pixel still has RGB channels. Extending the nearest visible edge color into transparent gutter pixels, while keeping alpha at zero, can prevent black or colored halos during interpolation.

Reproduce or challenge the result

The full benchmark publishes the JSON rows, CSV, comparison image, source bounds, threshold and limitations. It also maps the result to Unity and Godot settings:

https://www.framesprite.com/guides/sprite-sheet-padding-gutters?utm_source=devto&utm_medium=technical_article&utm_campaign=sprite_gutter_benchmark_20260831

If you run the data through a mipmap or platform-compression test, share the atlas settings and the first mip level where the result changes. That is the next experiment this small test does not answer.

The Eight-Direction Sprite Bug That Changes Between Godot and Unity

FrameSprite — Sun, 30 Aug 2026 07:04:20 +0000

Eight-direction sprite animation usually fails at the boundary between input, engine coordinates, and authored art. Godot 4 treats screen-up as negative Y, while a typical Unity 6 2D world treats up as positive Y. Keep movement analog, quantize only the visual-facing vector, and preserve the last non-zero direction while idle.

Start with one direction contract

Do not begin in the Animator or AnimationTree. Write the direction table first and use the same names in filenames, runtime code, and tests.

Direction	Godot 4 screen vector	Unity 6 world vector
East	`(1, 0)`	`(1, 0)`
North-east	`(0.7071, -0.7071)`	`(0.7071, 0.7071)`
North	`(0, -1)`	`(0, 1)`
North-west	`(-0.7071, -0.7071)`	`(-0.7071, 0.7071)`
West	`(-1, 0)`	`(-1, 0)`
South-west	`(-0.7071, 0.7071)`	`(-0.7071, -0.7071)`
South	`(0, 1)`	`(0, -1)`
South-east	`(0.7071, 0.7071)`	`(0.7071, -0.7071)`

This sign change is easy to miss during an engine port because every clip can still be named correctly. The wrong animation plays only when the vertical input reaches the runtime.

Movement and facing are separate values

An analog stick can produce hundreds of angles. An eight-view sprite can show only eight. Treating the same raw vector as both physical movement and visual selection creates unstable diagonals and makes idle behavior depend on input noise.

Use the raw, length-limited vector for movement. Normalize a copy and select the authored direction with the highest dot product:

best direction = direction with max(dot(normalize(input), candidate))

This creates deterministic 45-degree sectors. It also avoids a long chain of angle comparisons whose edge cases become difficult to audit.

In Godot 4, Input.get_vector() already limits the vector length. Send it to CharacterBody2D.velocity, then send the quantized copy to AnimationNodeBlendSpace2D.blend_position.

In Unity 6, physical movement can remain analog while MoveX and MoveY receive either the normalized input or the selected eight-way unit vector. Continuous input suits smooth motion. Pixel-art and hand-drawn views often read more clearly when the visual value snaps to one authored direction.

Idle needs an explicit policy

When input returns to zero, zero is not a direction. Choose one of two designs:

Use one neutral idle at the center of the blend space.
Store lastFacing and use a separate directional idle state.

The second option is required when a character should keep looking north-west after movement stops. Only update lastFacing when the input magnitude is above the dead zone. Otherwise small controller noise will cause idle flicker.

Test the boundaries, not just the eight labels

Testing N, NE, E, SE, S, SW, W, and NW proves only the obvious cases. Each sector changes at a 22.5-degree boundary. Probe values immediately on both sides of every boundary, then test:

low-magnitude gamepad input;
rapid reversal;
simultaneous opposite keys;
movement stopping near a boundary;
transition duration at native game scale.

If selection is still unstable, add a small amount of directional hysteresis so a new sector must beat the current sector by a margin before it wins.

The blend tree cannot repair source-art drift

Runtime setup is only half of the contract. Every directional clip also needs the same:

canvas dimensions;
semantic foot point;
pivot policy;
playback duration;
equipment placement;
direction naming order.

A different foot baseline can look like a BlendSpace2D or Animator bug. Compare the first frame of all eight clips in one scene before tuning transitions.

Complete engine implementations

The FrameSprite workflow team published both versions with code, failure tables, official engine references, and a downloadable cross-engine vector CSV:

The engine references used for the implementation are Godot's official AnimationNodeBlendSpace2D, AnimationTree, Input.get_vector, and CharacterBody2D documentation, plus Unity's official 2D Freeform Directional Blend Tree and Animator.SetFloat documentation.

Disclosure: I work on FrameSprite. The full method is included here so the post remains useful without following either link.
，

AI Game Art Is Not Engine-Ready Until You Define the Asset Contract

FrameSprite — Thu, 27 Aug 2026 22:03:08 +0000

An AI image can look finished and still be unusable in a game.

The failure usually is not visual quality. It is the missing agreement between art generation and the engine: dimensions, pivots, camera, stretch behavior, naming, frame cadence, and acceptance tests.

That agreement is the asset contract.

An asset contract is a small, explicit specification that says what the engine expects before anyone generates or draws the asset. It turns "make a fantasy panel" into "make a panel whose corners never deform, whose center can stretch, and whose text remains inside a known safe area."

This matters even more with generative tools. They can produce many plausible images quickly, which makes it easy to postpone technical decisions. Then the team discovers that the outputs cannot share a prefab, animation controller, atlas, or UI layout.

Here is how I define the contract for five common 2D asset families.

1. UI: define the 9-slice behavior before the decoration

A menu panel is not just a rectangle with an ornate border. It is a resizable component.

Before generating it, specify:

the native canvas size;
the left, right, top, and bottom cap widths;
which center regions may stretch or tile;
the text and icon safe area;
the smallest and largest intended aspect ratios;
required states such as default, hover, pressed, disabled, and selected;
whether corners and edge ornaments may overlap adjacent UI.

The fastest acceptance test is to apply the 9-slice settings in the engine and render the panel at three deliberately awkward sizes: tall, wide, and close to the minimum. Corners should retain their shape, edge motifs should not become rubbery, and the center should not reveal seams.

If the panel only works at the dimensions of the concept image, it is a mockup, not a component.

This AI game UI workflow shows the FrameSprite approach to generating around those implementation constraints.

2. Icons: review at runtime size, not presentation size

A 1024-pixel icon preview can hide every problem that matters in play.

The contract should name the real display sizes: perhaps 16, 24, 32, and 64 pixels. It should also lock:

silhouette complexity;
outer padding and alpha bounds;
background treatment;
stroke weight;
palette and contrast range;
lighting direction;
rarity or state markers;
atlas cell size and naming.

Review the icon set at 100% scale against the lightest and darkest surfaces in the actual UI. If the object class is not recognizable in a quick glance, extra detail will not save it.

Consistency across a set matters more than isolated polish. A sword, potion, key, and quest item should look as though the same visual system produced them.

The practical examples in this game icon generation guide focus on building that system rather than chasing one impressive image.

3. Eight-direction characters: directions are animation data

"Generate eight views" is underspecified.

First define the camera elevation and the canonical direction order. For example:

S, SW, W, NW, N, NE, E, SE

Then define the contract shared by every direction:

identical canvas dimensions;
a fixed feet pivot;
stable character scale and bounding box;
the same number of frames per action;
matching contact, passing, recoil, and recovery beats;
rules for handedness and asymmetric equipment;
direction and action naming conventions.

The feet pivot is especially important. When it drifts between directions, the character appears to slide or jump during turns even if each frame looks good alone.

Test the full directional set in a simple controller before producing every action. Walk a circle, change direction rapidly, and overlay the pivot. This exposes scale drift, camera drift, and inconsistent timing early.

Our eight-direction character sprite guide goes deeper on keeping identity and structure stable across the complete directional set.

4. True top-down characters: 90 degrees is a production choice

"Top-down" often gets interpreted as a high three-quarter view. That may look more expressive, but it is not the same camera.

A true 90-degree overhead character changes which planes are visible, how the head overlaps the torso, how weapons point, and how the sprite communicates facing. The contract should explicitly state:

camera pitch: 90 degrees overhead;
no visible horizon and no three-quarter facial view;
character center and ground-contact convention;
allowed shadow shape;
facing cues for head, shoulders, weapon, and feet;
rules for tall hats, backpacks, capes, and long weapons;
collision footprint versus visual footprint.

Place the sprite on a checkerboard map with props and narrow passages. If it appears to lean toward the camera or exposes too much of the front plane, the camera has drifted back toward three-quarter.

A true top-down sprite workflow is useful when the project needs overhead readability rather than an isometric-looking compromise.

5. Portraits: derive identity from the full-body master

Generating a portrait and a full-body character independently often creates two believable people who are not quite the same person.

Treat the approved full-body design as the identity master. Extract a short list of invariants:

face shape and skin tone;
hair silhouette and color;
headgear construction;
distinctive marks;
costume neckline and shoulder details;
core palette;
age, expression range, and rendering style.

The portrait contract then defines crop, head angle, eye line, lighting, background, expression variants, and output sizes. It should also say which costume details must remain visible to preserve recognition.

Compare portrait and full-body views side by side at their real UI sizes. Do not accept a portrait just because it is attractive; accept it when players can reliably connect it to the in-world character.

This portrait-from-full-body workflow demonstrates the reference-first method we use.

A compact contract template

Before generating an asset family, write down:

Runtime role — where and how the asset appears.
Output geometry — canvas, cell, crop, padding, and alpha rules.
View rules — camera, direction, pose, lighting, and scale.
Engine behavior — pivot, stretch zones, animation timing, and collision relationship.
Set consistency — palette, line weight, naming, and variant rules.
Acceptance tests — the exact engine scenes and sizes used for review.

This can fit on one page. The important part is that it exists before the first batch is generated.

Generation is the middle of the pipeline

A reliable workflow looks like this:

contract -> reference/master -> generation -> normalization -> engine import -> acceptance test

Prompting is only one step. Normalization and engine validation are what turn images into assets.

If a generated image fails the contract, regenerate or repair it before it enters the content library. Do not let exceptions accumulate inside prefabs and controller code. Technical debt in art pipelines is still technical debt.

Disclosure: I work on FrameSprite. The five links above point to FrameSprite guides. I included them because they document the concrete workflows behind these contract examples, not as neutral third-party recommendations.

From a 4 4 AI VFX Sheet to 16 Reproducible Game Frames

FrameSprite — Thu, 27 Aug 2026 08:56:51 +0000

An attractive VFX contact sheet is not automatically a usable game animation. The useful artifact is a sequence with an explicit contract that another developer can reproduce.

For one current FrameSprite sample, that contract is:

a 4×4 source sheet;
sixteen frames in left-to-right, top-to-bottom order;
a 512×512 canvas for every frame;
transparent PNG output numbered 000–015;
a one-second preview at 16 fps.

Validate motion before export

Reviewing sixteen thumbnails independently misses sequencing problems. I review the result as an onset, buildup, peak and decay. The exact phase boundaries can vary, but the sequence should not restart or reverse unexpectedly halfway through.

Validate alpha separately

A PNG can contain an alpha channel and still show a bright or dark halo in an engine. Preview the same frames on both light and dark backgrounds. RGB edge colors, premultiplication and the engine blend mode can produce different results even when the cutout looks clean in a browser.

Keep the engine boundary honest

The exported PNGs do not contain a Unity material, a Godot scene, a particle lifetime or a blend mode. They are lossless source frames. Those engine choices should remain explicit rather than being hidden behind a “game-ready” label.

I published the original frame pack, measured dimensions and the complete workflow here:

https://www.framesprite.com/guides/game-vfx-sprite-sheet-generator?utm_source=devto&utm_medium=technical_article&utm_campaign=vfx_16frames_20260827

Disclosure: I build FrameSprite. I would especially value reproducible feedback about the first engine/import combination you would test.