About

Frame-by-frame ASCII animation demands spatial reasoning across a discrete character grid. Each cell holds exactly one glyph from a set of 95 printable ASCII characters (code points 32 - 126). Timing errors compound: a single misplaced frame at f = 12 fps produces an 83 ms visual glitch that breaks perceived motion. This tool implements a full editing pipeline with onion skinning, flood fill via breadth-first search, and native GIF89a encoding with LZW compression for export. Grid dimensions are configurable up to 80 × 40 characters.

The tool approximates smooth motion through persistence of vision at configurable rates between 1 and 24 fps. Onion skinning renders the previous frame at reduced opacity so you can track motion deltas between frames. All project data persists in localStorage. Limitation: GIF export rasterizes glyphs onto a canvas, so output resolution depends on chosen font size. For terminal playback, use the plain-text export with frame delimiters.

Formulas

Playback timing derives from the frame rate. The interval between frames:

t_interval = 1000f ms

where f is the frame rate in fps. At f = 12 fps, each frame displays for 83.3 ms.

The flood fill algorithm uses BFS. Starting from cell (r, c) with target character t and replacement character r_char:

BFS(r, c): enqueue (r, c) → while queue ≠ ∅: dequeue (i, j) → if grid[i][j] = t: set r_char, enqueue 4-neighbors

GIF89a encoding uses LZW compression. The minimum code size m is derived from the color table size N:

m = max(2, ⌈log₂(N)⌉)

where N is the number of distinct colors in the palette (here 4: background, foreground, onion skin, transparent). Variable-length codes start at m + 1 bits and grow as the dictionary fills.

Reference Data

Character	Code Point	Common Animation Use	Visual Weight
.	46	Empty space / background dot	Light
#	35	Solid block / wall	Heavy
@	64	Character / entity center	Heavy
*	42	Sparkle / explosion particle	Medium
-	45	Horizontal line / ground	Light
\|	124	Vertical line / wall edge	Medium
/	47	Diagonal line (left-leaning)	Medium
\	92	Diagonal line (right-leaning)	Medium
_	95	Floor / underline	Light
=	61	Double horizontal / track	Medium
~	126	Water / wave motion	Light
^	94	Arrow up / mountain peak	Light
O	79	Circle / head / ball	Heavy
o	111	Small circle / bubble	Medium
:	58	Eyes / sparse pattern	Light
;	59	Wink / drip	Light
( )	40, 41	Curved body / shield	Medium
< >	60, 62	Arrows / mouth / beak	Medium
+	43	Crosshair / intersection	Medium
&	38	Dense fill / vegetation	Heavy
%	37	Texture / debris	Heavy
!	33	Exclamation / rain drop	Medium
'	39	Spark / apostrophe	Light
"	34	Double spark / steam	Light
(space)	32	True empty / transparency	None

Frequently Asked Questions

Onion skinning renders the previous frame's content at reduced opacity (typically 30%) behind the current frame on the canvas. This lets you see the character positions from frame N−1 while editing frame N, allowing you to track motion deltas and maintain consistent movement speed. Without it, aligning a moving character across frames requires constant frame-switching, which slows production significantly.

The BFS-based flood fill targets only cells matching the exact character at the clicked position. If you click a cell containing a period (.), only contiguous cells also containing periods are replaced. Diagonal cells are not considered neighbors - only 4-directional adjacency (up, down, left, right) is used. This prevents fill from leaking through diagonal gaps, which is the standard behavior in grid-based editors.

The GIF export rasterizes each frame onto an HTML Canvas using a monospace font. Output resolution equals columns × character width by rows × character height in pixels. The encoder supports up to 256 colors per frame (GIF89a spec), but this tool uses only 2-4 colors (background and foreground), so palette overhead is minimal. LZW compression is implemented natively in JavaScript, so encoding a 100-frame animation at 80×40 characters may take 2-5 seconds depending on device performance.

The tool supports up to 80 columns × 40 rows (3,200 cells per frame). Canvas rendering at this size remains smooth on modern devices. At 120×60 (7,200 cells), you may notice slight input lag on mobile devices. The bottleneck is not rendering but event handling - each mouse/touch move triggers a cell lookup calculation. For terminal-standard animations, 80×24 matches the classic VT100 terminal dimensions.

Each frame is exported as a block of text with exact row/column structure. Frames are separated by a configurable delimiter line (default: ---FRAME---). To play back in a Unix terminal, you can use a simple bash loop: clear the screen, cat each frame block, then sleep for 1/fps seconds. The export preserves trailing spaces so column alignment is maintained. No ANSI escape codes are included - it is pure ASCII.

Yes. The import function accepts plain text. Each line becomes a row. Lines shorter than the grid width are right-padded with spaces. Lines longer are truncated. If the text has more lines than the grid height, excess lines are discarded. This lets you paste ASCII art from any source and use it as a base frame for animation.