From 8147fb1110fd0037610de6701e83ccd29f4d0432 Mon Sep 17 00:00:00 2001 From: Sadeep Madurange Date: Thu, 25 Dec 2025 22:48:14 +0800 Subject: Use the full post instead of the log for Matrix. --- _log/matrix-digital-rain.md | 146 ++++++++++++++++++++++++++++++++++++++------ 1 file changed, 129 insertions(+), 17 deletions(-) (limited to '_log') diff --git a/_log/matrix-digital-rain.md b/_log/matrix-digital-rain.md index 4958eed..b691e84 100644 --- a/_log/matrix-digital-rain.md +++ b/_log/matrix-digital-rain.md @@ -1,34 +1,146 @@ --- -title: 'Matrix Rain: 2025 refactor' +title: Recreating the Matrix rain with ANSI escape sequences date: 2025-12-21 layout: post project: true thumbnail: thumb_sm.png --- -Unicode support added. ASCII + Katakana working: +My 2022 implementation of the Matrix rain had too many loose ends. Unicode +support was inflexible: the character set had to be a single contiguous block +with no way to mix ASCII with something like Katakana; Phosphor decay level was +stored in a dedicated array--still don't understand why I did that when I had +already used bit-packing for the RGB channels; The algorithm was difficult to +decipher. The 2022 version worked, but that’s not the same thing as correct. - +I began by placing the decay factor in the MSB of the 4-byte RGB value. The PD +value plays a somewhat analogous role to an alpha channel in that both +influence transparency. However, they work very differently. So, I avoided +labelling it A so as not to cause confusion: + +``` +enum { + R, /* Red */ + G, /* Green */ + B, /* Blue */ + PD /* Phosphor decay level */ +}; + +typedef union color_tag { + uint32_t value; + unsigned char color[4]; +} color; +``` + +The decision to use union over more portable bit twiddling was made three years +ago, as I recall, for readability. Seeing as all my systems are little-endian, +this is unlikely to cause any trouble. Besides, if union is never to be used, +why is it in the language anyway? + +The blend() function, which emulates the dim afterglow of Phosphor by eroding +the RGB channels towards the background, with minor refactoring, remains as +elegant as it did three years ago: + +``` +#define DECAY_MPLIER 2 + +static inline void blend(matrix *mat, + size_t row, size_t col) +{ + unsigned char *color; + + color = mat->rgb[index(mat, row, col)].color; + color[R] = color[R] - (color[R] - RGB_BG_RED) / DECAY_MPLIER; + color[G] = color[G] - (color[G] - RGB_BG_GRN) / DECAY_MPLIER; + color[B] = color[B] - (color[B] - RGB_BG_BLU) / DECAY_MPLIER; +} +``` + +While the memory inefficiency of Phosphor decay was a technical oversight I +hadn't noticed, the limitation around mixing nonadjacent Unicode blocks was a +nagging concern even three years ago. So, a fix was long overdue. -Algorithm notes: mat.col[] = shuffled column indices, mat.row[] = last row per -column. shuffle() sets working set, main loop draws columns via index i (line -333), swap() rotates set. +In the new version, I introduced an array that enables a user to add as +many Unicode blocks as they want. The insert_code() function picks a block +from it at random, and then picks a character from that block at random: -Phosphor decay moved to LSB of RGB union. Should have done this originally. +``` +#define UNICODE(min, max) (((uint64_t)max << 32) | min) -RGB/PD union stays. Little-endian machine, portability not a concern. +static uint64_t glyphs[] = { + UNICODE(0x0021, 0x007E), /* ASCII */ + UNICODE(0xFF65, 0xFF9F), /* Half-width Katakana */ +}; -Charset via UNICODE(min, max) macro - packs range into uint64, insert_code() -unpacks and selects random char. +static uint8_t glyphlen = (sizeof glyphs) / (sizeof glyphs[0]); -Half-width Katakana (U+FF61-U+FF9F) for column alignment. +static inline void insert_code(matrix *mat, + size_t row, size_t col) +{ + uint64_t block; + uint32_t unicode_min, unicode_max; -Removed license, automake files. Build: cc -O3 main.c -o matrix + block = glyphs[(rand() % glyphlen)]; + unicode_min = (uint32_t)block; + unicode_max = (uint32_t)(block >> 32); + + mat->code[index(mat, row, col)] = rand() + % (unicode_max - unicode_min) + + unicode_min; +} +``` + +The Unicode blocks are stored in 8-byte containers: the low four bytes form the +first codepoint and the high four bytes the last. Here, I chose bitwise +operations over unions because, first and foremost, the operations themselves +are trivial and idiomatic, and the UNICODE() macro simplifies the management of +charsets. + +The init_term() function is the arbiter of this zero-dependency software. It +prepares the graphical environment so that I can interact with it via ANSI +escape codes instead of unnecessary layers of abstraction: + +``` +static inline int init_term(const struct winsize *ws) +{ + struct termios ta; + + if (tcgetattr(STDIN_FILENO, &ta) == 0) { + ta.c_lflag &= ~ECHO; + if (tcsetattr(STDIN_FILENO, TCSANOW, &ta) == 0) { + wprintf(L"\x1b[48;2;%d;%d;%dm", + RGB_BG_RED, RGB_BG_GRN, RGB_BG_BLU); + wprintf(L"%s", ANSI_FONT_BOLD); + wprintf(L"%s", ANSI_CRSR_HIDE); + wprintf(L"%s", ANSI_CRSR_RESET); + wprintf(L"%s", ANSI_SCRN_CLEAR); + setvbuf(stdout, 0, _IOFBF, 0); + ioctl(STDOUT_FILENO, TIOCGWINSZ, ws); + return 1; + } + } + return 0; +} +``` + +insert_code() seeds the Matrix, blend() creates the old monochrome CRT display +nostalgia, and ANSI control sequences paint the screen. The result is a digital +rain that captures the original Matrix aesthetic with high visual fidelity: + +``` +$ cc -O3 main.c -o matrix +$ ./matrix +``` + + -Performance: 2% CPU, OpenBSD, T490. +There was no cause to measure the program's performance characteristics +precisely; it's gentle on the CPU. On my ThinkPad T490 running OpenBSD, which +has a resolution of 1920x1080, it uses about 2-3% of the CPU, with occasional +jumps of up to about 8%; the cores remain silent, the fans don't whir, the rain +falls in quiet. -Commit: -[03f8d87](https://git.asciimx.com/matrix-digital-rain/commit/?id=03f8d87ba7c2e46bd3f3cc4c772fb3a2ac740c92) +Files: [source.tar.gz](source.tar.gz) -- cgit v1.2.3