24 aug 2020 @ justine's web page
I've always thought demos like 8088 MPH were cool. Here's what's peculiar. Microsofties know all about this sort of thing. They're the best at graphics so they consider textmode art like blocktronics to be an obsolete nostalgia.
On the other hand, textmode continues to be the modus operandi of Linux professionals to this date, even though they've had surprisingly little exposure to its most intertesting capabilities. It might come as a surprise to some people that old technologies continue to be so popular. It's just that folks like Googlers who sit around typing in Havoc Pennington's black box all day, typically don't tweet about it. So I decided to start bringing more ANSI art culture to Linux back in 2013 by releasing Hiptext.
One of the properties of GNU/Linux code is it tends to approach read-only on a long enough timeline, in the absence of continual maintenance. That partly explains why we can't compile old GCC, or what may have frightened off John Carmack when he tried to share Quake with the Linux community. Hiptext too, sadly enough, suffered a similar fate. Today it probably only builds inside a Docker container.
Ideally I'd prefer that my personal laziness not have consequences, such as not being able to build my own software anymore due upstream to api churn in things like libav. So I spared no expense figuring out a legally respectful way to use GNU tools to build programs that obfuscate the need for much of the maintenance burnout we've seen, similar to how the Super Mario Bros ROM file has managed to survive for decades without too many GitHub issues.
This prog is called PRINTVIDEO.COM and it uses a DOS-inspired binary structure overlaid with a Docker-inspired PKZIP filesystem in order to do things with Unix terminals that they were never intended to do, like printing crab videos. One day it'll be fully functional on metal, but here's what `$ printvideo.com -ts crabrave.mpg # source` looks like today in HD textmode on Debian via SSH in Simon Tatham's teletypewriter using PL_MPEG decoding, Facebook Magikarp Photoshop cubic sharpen decimation, and Fabrizio Schiavi's most supremely fabulous PragmataPro.
In some respects, a toy television requires a higher standard of engineering than a GUI like VLC due to the apparentness of mathematical errors in an environment with so few oblong pixels. So the sources might serve as interesting reference material. They are optimized for clarity, similar to projects like Redis, and should hopefully provide an approachable concise explanation for how certain magic numbers in ITU/CIE/ISO recommendations or Bruce Lindbloom's website can be derived. Derasterizing MPEG to a 90 column × 25 line teletype display also makes subpixel rasterization (those boring low-level algorithms tech giants spent the last few decades suing each to control) feel like kids stuff by comparison.
PRINTVIDEO.COM should also go fast enough to render 4K video on an old ThinkPad without needing APIs or GPUs, since experience has led me to believe it's easier to make code go fast on CPUs. It's not hard. I recommend reading Intel's 6,000 page manual. If you've had the pleasure of working with Nvidia, consider reading it twice. In fact, it actually takes less CPU to decode + convolve + render high definition video than it does for OpenSSH and Zlib to copy the finished text to ethernet, possibly due to the muh portable k8 side channel arguments we've seen from the usual suspects so far. You'll also find elegant implementations of Hilbert curve quantization, unicode shade block interpolation, chromatic adaptation, and the kind of actually linear algebra that Eric Brasseur loves.
download
printvideo.com (372k PE+ELF+MachO+ZIP+SH)
source code
printvideo.c
magikarp.c
gyarados.c
ycbcr2rgb3.c
cdecimate2xuint8x8.c
getintegercoefficients.c
differsumsq.c
ttyraster.c
dither.c
idct.c
illumination.sh
dinlerp.c
see also