ASCIImotion: Working With a Text Grid

ASCII rendering is a useful constraint because it removes most of the usual visual tools. There are no gradients to hide behind. The output is a grid of characters, and the quality comes from density, timing and control.

ASCIImotion started from that constraint: make image and video processing work in the browser, keep the interface direct, and export something people can actually use.

Rendering

A DOM node per character is the wrong shape for realtime playback. The renderer treats each frame as a text surface, then updates that surface directly. It is not the most abstract design, but it keeps the frame loop understandable and fast enough for the product.

The lesson is simple: the browser does not reward purity when the product is a visual tool. Use the rendering model that fits the medium, then keep the rest of the system boring.

Fonts

ASCII output changes with the font. The same character map can look dense in one monospace face and loose in another. Trying to predict every rendering context would add complexity without giving the user much control.

The tool focuses on the controls that survive across fonts: character density, contrast, mapping and edge detection. Final typography stays in the user’s hands.

Product shape

The useful version was not a large feature set. It was a tight loop:

• Import image or video
• Adjust the ASCII interpretation
• Preview motion without breaking timing
• Export a file or data format that can leave the tool

That loop drove the implementation. Undo, frame state and export handling were kept explicit and snapshot-based, because predictability mattered more than clever state machinery.

ASCIImotion is open source and available at asciimotion.gx2-studio.com.