From 1b991a54cc834e8ef9ccc8bb15dce7ff70cdf8a3 Mon Sep 17 00:00:00 2001 From: Sadeep Madurange Date: Wed, 24 Dec 2025 16:29:32 +0800 Subject: Matrix post. --- _site/log/matrix-digital-rain/index.html | 125 ++++++++++++++++--------------- 1 file changed, 63 insertions(+), 62 deletions(-) (limited to '_site/log/matrix-digital-rain/index.html') diff --git a/_site/log/matrix-digital-rain/index.html b/_site/log/matrix-digital-rain/index.html index 6007da5..4a23d29 100644 --- a/_site/log/matrix-digital-rain/index.html +++ b/_site/log/matrix-digital-rain/index.html @@ -44,40 +44,60 @@

RECREATING THE MATRIX RAIN WITH ANSI ESCAPE SEQUENCES

21 DECEMBER 2025

-

The Matrix digital rain implemented in raw C using ANSI escape sequences with -zero dependencies—not even ncurses.

- - +

My 2022 implementation of the Matrix rain had too many loose ends. Unicode +support was inflexible: the charset 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 being correct.

+ +

I began by placing the decay factor in the LSB of the 4-byte RGB value. Let’s +call that RGB-PD. PD plays a somewhat analogous role to an alpha channel; I +avoided labelling it A so as not to cause confusion:

+ +
enum {
+    R,  /* Red   */
+    G,  /* Green */
+    B,  /* Blue  */ 
+    PD  /* Phosphor decay level */
+};
 
-
This is a fork of Domsson’s unique rendition of the Matrix rain: Fakesteak. Three years ago, I forked his project
-and added truecolor and Unicode support. I also drastically modified the
-algorithm to produce a rain that resembled the original aesthetic with high
-visual fidelity.

+typedef union color_tag {
+    uint32_t value;
+    unsigned char color[4];
+} color;
+
-

Unicode support

+

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 me trouble. Besides, if union is never to be used, +why is it in the language anyway?

-

Unicode support in the 2022 version lacked flexibility. The charset used in the -rain had to be a single contiguous block defined by UNICODE_MIN and -UNICODE_MAX settings:

+

The blend() function, which emulates the dim afterglow of Phosphor by eroding +the RGB channels towards the background, remains as elegant as it did three +years ago:

-
#define UNICODE_MIN 0x0021
-#define UNICODE_MAX 0x007E
+
#define DECAY_MPLIER  2
 
-static inline void insert_code(matrix *mat,
-    size_t row, size_t col) 
+static inline void blend(matrix *mat,
+    size_t row, size_t col)
 {
-    mat->code[index(mat, row, col)] = rand()
-        % (UNICODE_MAX - UNICODE_MIN)
-        + UNICODE_MIN;
+    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;
 }
 

 
-
There was no way, for instance, to use both ASCII and Katakana at the same
-time. The user had to pick one. In the new version, the user can use any number
-of Unicode blocks using glyphs array. In fact, the default rain now includes
-both ASCII and half-width Katakana characters:

+
While the memory inefficiency of Phosphor decay tracking 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 a glyphs array that enables a user to add as
+many Unicode blocks as they want. The insert_code() function picks a block
+from the array at random, and then picks a character from that block at random:

 
 
#define UNICODE(min, max)  (((uint64_t)max << 32) | min)
 
@@ -104,51 +124,32 @@ static inline void insert_code(matrix *mat,
 }
 

 
-
Entries in the glyphs array are Unicode blocks bit-packed in an 8-byte
-container: the four low bytes forms the first codepoint and the four high bytes
-the last.

-
-
Phosphor decay

+
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 insert_code() function is now ready to take its rightful place
+next to blend().

 
-
The dim afterglow of monochrome CRT displays is achieved by carefully scaling
-the RGB channels individually and mixing them:

-
-
#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;
-}
-

-
-
The blending function emulates the phosphor decay by gradually transitioning
-each raindrop’s color towards the background color. The multiplier is the
-number of passes over the rain track needed before the afterglow disappears.

-
-
The algorithm

-
-
Nonetheless, the rain resembles the original with high visual fidelity. It’s
-highly customizable and gentle on the CPU. On my 14” ThinkPad T490, which has a
-resolution of 1920x1080 and 4GHz CPU, it uses 2-3% of the CPU with occasional
-jumps of up to about 8%. Not too bad for a weekend project. The program has
-been tested with xterm and urxvt terminal emulators on OpenBSD and Arch Linux
-systems. Someone has managed to get it moving on a Raspberry Pi as well.

-
-
Lastly, to compile and run:

+
The result is a digital rain that captures the original Matrix aesthetic with
+high visual fidelity:

 
 
$ cc -O3 main.c -o matrix
 $ ./matrix
 

 
-
“All I see is blonde, brunette, red head.”

+
+
+
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.

 
 
Files: source.tar.gz

+

by W. D. Sadeep Madurange

-- cgit v1.2.3