diff options
| author | Sadeep Madurange <sadeep@asciimx.com> | 2025-12-24 19:21:25 +0800 |
|---|---|---|
| committer | Sadeep Madurange <sadeep@asciimx.com> | 2025-12-25 17:25:16 +0800 |
| commit | 51f8430027ceaf7590d826221230cbe2fc1af2ec (patch) | |
| tree | e0940b013f8edebbdf70c04f0bd1c722e9ed5f56 /_log/matrix-digital-rain.md | |
| parent | abf2ae336b780ac206e3f5d55b608703c9d807d5 (diff) | |
| download | www-51f8430027ceaf7590d826221230cbe2fc1af2ec.tar.gz | |
Change to log/journal style.
Diffstat (limited to '_log/matrix-digital-rain.md')
| -rw-r--r-- | _log/matrix-digital-rain.md | 153 |
1 files changed, 26 insertions, 127 deletions
diff --git a/_log/matrix-digital-rain.md b/_log/matrix-digital-rain.md index b97bb7a..d4ea301 100644 --- a/_log/matrix-digital-rain.md +++ b/_log/matrix-digital-rain.md @@ -1,146 +1,45 @@ --- -title: Recreating the Matrix rain with ANSI escape sequences +title: 'Matrix Rain: 2025 refactor' date: 2025-12-21 layout: post project: true thumbnail: thumb_sm.png --- -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. +Fixed the Unicode issue finally. Can now mix ASCII + Katakana. -I began by placing the decay factor in the LSB 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: +Took me 2 hours to decipher how this even works. For future me: mat.col[] +stores shuffled column indices, mat.row[] tracks last updated row per column. +shuffle() randomizes the working set, index i (line 333) and lines 364-370 draw +one column at a time, swap() rotates columns in and out. That's the rain. -``` -enum { - R, /* Red */ - G, /* Green */ - B, /* Blue */ - PD /* Phosphor decay level */ -}; +Moved Phosphor decay level into the LSB of the RGB union - should've done this +in 2022 instead of separate array. WTF was I thinking? -typedef union color_tag { - uint32_t value; - unsigned char color[4]; -} color; -``` +Keeping the RGB/PD union as it is. I know the 'portability' nerds hate it, but +I’m on a little-endian machine, and I’m the only one reading this. It’s +cleaner. -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? +New charset array works. UNICODE(min, max) macro packs the range into uint64. +insert_code() picks random block, unpacks it, and picks random char. Elegant. -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. - -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: - -``` -#define UNICODE(min, max) (((uint64_t)max << 32) | min) - -static uint64_t glyphs[] = { - UNICODE(0x0021, 0x007E), /* ASCII */ - UNICODE(0xFF65, 0xFF9F), /* Half-width Katakana */ -}; - -static uint8_t glyphlen = (sizeof glyphs) / (sizeof glyphs[0]); - -static inline void insert_code(matrix *mat, - size_t row, size_t col) -{ - uint64_t block; - uint32_t unicode_min, unicode_max; - - 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 -``` +Looks a lot like the original now: <video style="max-width:100%;" controls="" poster="poster.png"> <source src="matrix.mp4" type="video/mp4"> </video> -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. +Using half-width Katakana (U+FF61-U+FF9F) because full-width characters break +columns. + +blend() is still good, left it alone. + +Tossed the license and automake cruft. Just `cc -O3 main.c -o matrix`. Don't +need the ceremony. + +Performance regressions: none. Runs like a charm on the T490. 2% CPU. No +whirring fans. -Files: [source.tar.gz](source.tar.gz) +Commit: +[03f8d87](https://git.asciimx.com/matrix-digital-rain/commit/?id=03f8d87ba7c2e46bd3f3cc4c772fb3a2ac740c92) |
