ubunatic.com

Terminal & TUI Stack

loom-games Doom in any Terminal

loom-doom renders live Chocolate Doom frames as ANSI colors and Unicode glyphs, with half-block, quad, or sextant modes.

Key facts

12-week commit activity

2026-10-26
View 12-week data table
Week startingCommits
2026-08-030
2026-08-100
2026-08-170
2026-08-240
2026-08-310
2026-09-070
2026-09-140
2026-09-210
2026-09-28230
2026-10-0556
2026-10-120
2026-10-190

Key Features

  • Runs Chocolate Doom and paints its live frames with colored half, quarter or six-part terminal blocks.
  • A transparent window captures mouse and keyboard on GNOME Wayland while Doom stays in the terminal.
  • An on-screen display reports frame rate, frame timing and rendering activity.
  • Snake difficulty and display options come from YAML specifications.

Verified Engineering Milestones

  • Chocolate Doom rendered in the terminal (#018, #019, a4e837e, 4ac7f64)
  • Desktop input capture verified on GNOME Wayland (#035, #036, dcb3f38)
  • Multi-level render telemetry HUD (#048, 07fb41c)

Stack

Go 1.26.0, C, Loom, Cati, Cobra, SDL2/SDL3, POSIX shared memory, YAML specs, JSON Schema

Why loom-games

A Snake prototype became a test bed for a harder question: how far can terminal rendering go? Doom brings a real game’s pixels and responsive controls into the terminal, exposing the boundaries between game rendering, terminal geometry, and desktop input.

What it does

Three glyph modes

Go maps captured pixels into half-block, quad, or sextant Unicode cells, fitting Doom’s 320×200 frame to terminal geometry.

Desktop input capture

A transparent SDL capture surface forwards mouse and key events while the game remains visible in the terminal. Terminal and hybrid input paths are also documented.

Measured rendering

Telemetry, repaint benchmarks, and real-frame probes make rendering performance and frame recognition inspectable.

The SDL rendering path is captured and turned into terminal cells.

Recent milestones

Historical milestones from the review through October 4, 2026.

Testing the desktop boundary

The capture surface was opaque on Wayland; later attempts left a magenta glow. Direct compositor canaries exposed the need for a borderless, windowed-fullscreen SDL3 surface and premultiplied pixels. Frame matching also moved beyond synthetic fixtures: the recorded real-frame probe recognized the status bar in 119/120 samples and health and ammo in 114/115, with a screen transition accounting for the miss.

The October 4 review records 313 commits in six weeks, 63 numbered tickets, and 170 test functions: evidence of pace and breadth across Go, C, SDL, and terminal protocols.

Read the full October 4 story and its facts table.

Current scope and limits

Doom has been tested and is playable in the seven terminals listed below. That evidence does not establish support in every terminal. Issues 061 and 062 still track live checks for grab bindings and renderer cycling. Chocolate Doom is GPL-licensed, and running Doom requires separately supplied, legally obtained WAD game data.

Tested terminals

Owner-reported testing found Doom playable in each of these terminals.

Terminal Status
Tilix Tested and playable
Foot Tested and playable
Kitty Tested and playable
Ptyxis Tested and playable
CRT Tested and playable
xfce4-terminal Tested and playable
Alacritty Tested and playable

Renderer performance work in Cati and Loom Games included patches from Google Jules, a cloud coding agent; the changes were reviewed and integrated. See the Loom Games study and the Cati study.

Explore the source

See the source repository for build requirements and project documentation, or browse releases.

Project details

Stack
Go 1.26.0, C, Loom, Cati, Cobra, SDL2/SDL3, POSIX shared memory, YAML specs, JSON Schema
Milestones
Chocolate Doom rendered in the terminal (#018, #019, a4e837e, 4ac7f64) · Desktop input capture verified on GNOME Wayland (#035, #036, dcb3f38) · Multi-level render telemetry HUD (#048, 07fb41c)

Layer composition

Terminal
Unicode blocks, ANSI true color, TUI
Desktop
Linux, Wayland/X11, SDL2/SDL3
Inference / AI
—
Containers / VM
—
Web
—

loom-games: the story behind the project

Loom Games started with a small ambition: make a Snake game that feels at home in a modern terminal. Its early work separated game rules from screen drawing, described the interface in ANSI mockups, and put tunable values in an embedded YAM…

Read the engineering story