assets

Assets

cover.png

The project's own reduction of the composition on the lid of the 1962 TwixT box, published by the Minnesota Mining and Manufacturing Company (3M) in its bookshelf game series: the wordmark, the player resting his chin on his hand, two tall red pegs flanking a row of linked black pegs over a field of holes. The reduction was drawn as a flat poster — hard edges, a handful of colours, none of the photographic texture a terminal cannot represent. The reference was a photograph of a 1962 box lid published at vintagegamenight.com, used as reference only and not redistributed here. The original lid artwork is © 1962 3M; the repository owner decided the project ships this reduction and treats the projection into terminal characters as the alteration.

The shipped file is deliberately small (213x320, sixteen colours): the picture is only ever drawn as character cells, so detail beyond about twice the densest cell grid would be bytes every binary carries for nothing. cover-source.png is that full-resolution source, 1024x1535, carried here so the recipe below is not a dead one. A regeneration command whose input lives only in somebody's temporary directory turns the shipped file into a blob the moment that directory is cleared, which is the thing this note exists to prevent.

Regenerate with:

go run ./assets/gen -in assets/cover-source.png -out assets/cover.png -colors 16

The generator reduces by area-averaging in linear light — the same filtering the renderer in internal/cover applies — and then snaps the result back onto its own dominant colours, so flat art stays flat instead of carrying thousands of one-off edge blends.

The SVG files below are for the documentation rather than for the program: nothing in the binary reads them. They are SVG, which is to say they are their own source — text, diffable, edited in place — so unlike cover.png they need no regeneration recipe. What they do need is the record of which facts in the code they are repeating and which parts are only illustration, because a picture that quietly stops agreeing with the program is worse than no picture. That is what each note below is for.

banner-light.svg, banner-dark.svg, banner-compact-light.svg, banner-compact-dark.svg

The supplied 1280×320 front-page artwork places a cream-framed illustration of the 1962 box lid beside a shell prompt. The card holds the stencil wordmark, mauve sky, golden board, a receding chain of dark pegs and two tall red flankers. The type beside it names the project and shows twixtui play bot --tier pro --side vertical.

This is an illustration, not a screenshot or a playable board position. Its perspective and peg placement serve the composition; board.svg below is the documentary rendering of an actual position. The supplied illustration is preserved; non-rendering export metadata has been omitted.

The palette draws on internal/cover/homage.go, with local shades for the highlights, clouds, holes and frame. The project name uses the classic scheme's red and blue from internal/theme/theme.go, and the cursor uses its yellow. A GAME OF BARRIERS FOR TWO is the project's homageTagline, not a quotation from the original lid.

README.md picks one of the four with <picture>. The first two <source> elements carry (max-width: 480px) and hand a narrow viewport the compact pair; the third carries prefers-color-scheme: dark on its own, and the <img> fallback is the light wide file. First match wins, so a wide dark page takes banner-dark.svg and a phone in dark mode takes banner-compact-dark.svg. All four have the same composition elements and a transparent canvas; the type and illustration colours change to suit the page background.

The compact pair exists because the wide arrangement does not survive being scaled to a phone. At a 390-pixel viewport the 1280-wide file draws the command line at about five pixels, which is texture and not type. banner-compact-*.svg is 500×470: the same card — the wide file's artwork group verbatim, drawn at 0.9 — stacked above the same four lines of type instead of set beside them, which puts the command near twelve pixels and the subtitle near nineteen on that same surface. The length of $ twixtui play bot --tier pro --side vertical is what sets the ceiling: it is forty-six monospace cells that must cross the column unbroken, and the file already spends 92% of its width on them. Above the breakpoint the wide files are used with their original layout and a text-flow cursor. The compact files keep the same illustration and wording while making the type readable in a narrow column.

Neither pair uses a script, a foreignObject or a webfont: they are static shapes and text in system font stacks.

The block cursor is the last glyph of the command's own text run rather than a rectangle at a measured position. It therefore follows the end of the line whatever width the reader's monospace font resolves to, and editing the command does not need a second edit to move it.

TwixT is Alex Randolph's game. The historical lid artwork is © 1962 Minnesota Mining and Manufacturing Company (3M); the project's cover-reference history is recorded under cover.png above.

board.svg

The position printed as characters under "The board" in docs/MANUAL.md, drawn again in colour; the manual shows this file below that character block. It is a rendering and not a screenshot: the glyphs are taken from that code block and the colours are applied to them here. Nothing was captured from a terminal, and the file does not claim otherwise.

Both halves of that are pinned to the code. The palette is the classic scheme from internal/theme/theme.go, hex for hex. Which colour reaches which glyph follows internal/ui/theming.go and the styleID table in internal/ui/theme.go: holes take Grid, pegs take VerticalPeg and HorizontalPeg in bold, link strokes take VerticalLink and HorizontalLink, the peg just played takes LastMove rather than its owner's colour, the cursor brackets take Cursor while the hole between them stays a hole, and the gutter numbers of the top and bottom rows and the outermost column letters take their own player's colour unbolded, the rest BorderRow. Five of those roles were also checked against a real render rather than only against the source: twixtui --theme classic learn board in a 200x50 tmux pane, read back with capture-pane -e, emits exactly the hex this file uses for holes, for the gutter and column labels, for both players' pegs and for the cursor brackets. The link colours and LastMove are taken from the source alone, because that lesson opens on a position with no links on it and no peg just played, so the capture had nothing to say about them.

Which stroke belongs to which player cannot be read off a glyph, because a run of - looks the same whoever owns it. It was resolved from the geometry: each pair of same-coloured pegs a knight's move apart was tested for the cells the renderer would draw it in, a steep link occupying the one diagonal cell between its ends and a shallow link three cells across plus a corner. That accounted for all fifty-three link cells with none contested and none left over, and it left the M12-O11 link undrawn, which is the blocked link the caption is about. A wrong guess at ownership would have coloured that argument backwards.

The background is the one colour here that no scheme provides: no theme paints a background, since pegs and links sit on whatever colour the player's terminal already is. classic is a scheme for a dark terminal, so the file supplies a dark one to stand in for it.

Introductory video

twixtui-demo.mp4 is the 68.3-second historical illustrative tour linked from the README and website. It recreates an earlier three-tier interface, before max and the placement-only hint labels; it is not a recording of the current release. Its storyboard is retained with the movie, not presented as current UI documentation. Use docs/MANUAL.md for today's controls and search policy.

The sequence and artwork come from the supplied design. The relay camera shows each command at close range before the two-window overview, and its example uses a complete sample pairing code. The hint panel is labelled illustrative rather than claiming measured search results.

The movie is H.264, 1280×720, 30 frames per second, without audio. Its MP4 header is at the front of the file for progressive playback. demo-poster.png is the menu scene at ten seconds. Both are documentation assets; the game binary embeds only cover.png.

The historical storyboard and export command are in demo/. Exporting reproduces that earlier tour, not the current release. From the repository root:

bun install --cwd assets/demo --frozen-lockfile --ignore-scripts
bun run assets/demo/render.mjs

Export requires Bun, Chrome or Chromium, and ffmpeg with libx264. Set CHROME or FFMPEG to an executable path if it is not found automatically. The source preview also loads pinned React/ReactDOM/Babel from unpkg and JetBrains Mono from Google Fonts, so export needs network access. These are authoring tools, not dependencies of the game or the public website.

The exporter starts a loopback-only source server and a fresh headless browser, seeks each of the 2,049 frames synchronously, and passes PNG frames to ffmpeg. It replaces the movie and poster only after encoding succeeds. An optional output-directory argument keeps an experimental render outside assets/:

mkdir -p /tmp/twixtui-demo
bun run assets/demo/render.mjs /tmp/twixtui-demo

For GitHub's inline README player, upload the finished MP4 as a GitHub attachment and use its returned URL. Committing an MP4 or linking its raw repository URL does not create that player. Uploading the attachment is a publication step even if no issue, comment or README edit is submitted. Keep the stable attachment URL in README.md, not the temporary signed media URL returned by the Markdown renderer. GitHub removes custom video posters, so its native player starts with the movie's shell-opening frame; demo-poster.png is retained as a separate still for other presentation surfaces.