Pixel covers drawn in code: how this blog's art is made
Every post on this blog has its own animated pixel-art cover, and none of them is an image file. How they're drawn: a 128×128 grid, four greens, dithering, a tiny font, and a scene that runs as a function of time.
Request an AI summary
Every post on this blog has a little animated scene as its cover: a moving truck labelled 301, a racing car under a sunset, a tape deck copying a cassette. In each one, the onigiri from the site’s game plays the lead. None of these covers is an image or a video. Each one is a few dozen lines of code that draw the scene, pixel by pixel, while you watch.
Here’s how that works, and why it’s built this way.
1. The canvas: 128 by 128 pixels
Each cover is drawn into a grid of 128 by 128 pixels, the resolution of a small handheld screen from the 90s. The browser scales it up to the size of the cover with crisp, square pixels instead of blurring them. So the art stays sharp on every screen, from a phone to a large monitor, without needing a larger file.
2. The palette: four greens
Every cover uses the same four colours: the black and greens of the site’s design, from almost black to the bright hero green. Four tones were the whole palette of classic handheld consoles, and the limit gives all covers a common look, the same way a brand palette does for a website.
3. Dithering: more shades from four colours
Four colours sound like very little for skies, glows and shadows. The trick is dithering: a fixed pattern of pixels decides, for each spot, whether it takes the lighter or the darker of two neighbouring tones. From a normal viewing distance, the eye blends them into in-between shades. A sunset gets its gradient, a lamp its glow, all from four colours.
4. The pen: a handful of tools
All scenes are drawn with the same small set of tools, like in an old paint program:
- Rectangles and ovals for screens, buttons, wheels and suns.
- Lines for antennas, handles and arcs.
- Shading that fills an area with a computed tone, dithered down to the palette.
- Sprites: small pixel pictures written as rows of digits, such as the onigiri itself, 16 by 16 pixels.
- A 3×5 pixel font for labels like “PASS”, “301” or “RESTORE OK”.
5. Time: every frame is a function
Each scene is a pure function of time: given the number of seconds since the cover appeared, it draws exactly one frame. Nothing is stored between frames. That keeps every scene simple to reason about, and it allows three useful things:
- The story restarts each time the cover scrolls into view.
- A click or tap makes the onigiri jump, because the time since the last click is passed in as well.
- Reduced motion is covered: visitors who prefer less movement see one chosen moment of the scene, a still frame picked to tell the story on its own.
The animation only runs while the cover is on screen.
6. Size: code instead of files
A whole scene is a few kilobytes of code, smaller than a single compressed photo, and all covers share the same drawing tools. There are no image files to download for them, and the covers still move. For a blog whose posts talk about fast websites, that felt right.
7. The rules: generic and recognisable
The scenes follow a few rules. Each one shows its post’s topic in a simple way, with gadgets and games from the 80s and 90s that most people recognise: a tape deck, a fortune ball, a level map. They stay generic, with no brand names, logos or real characters. And the onigiri is always there.
The short version
- 128×128 pixels, scaled up with crisp edges.
- Four greens, the site’s palette and the classic handheld limit.
- Dithering turns four colours into gradients and glows.
- A small pen: rectangles, ovals, lines, shading, sprites and a 3×5 font.
- A function of time: restarts on view, reacts to clicks, a still frame for reduced motion.
- A few kilobytes of code per scene, no image files.
If your brand could use its own playful visuals, get in touch.