Matrix post.

1 files changed, 63 insertions, 64 deletions

diff --git a/_log/matrix-digital-rain.md b/_log/matrix-digital-rain.md
index 2c35361..8c97ed3 100644
--- a/_log/matrix-digital-rain.md
+++ b/_log/matrix-digital-rain.md
@@ -6,43 +6,62 @@ project: true
 thumbnail: thumb_sm.png
 ---
 
-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.
 
-<video style="max-width:100%;" controls="" poster="poster.png">
-  <source src="matrix.mp4" type="video/mp4">
-</video>
+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: <a
-href="https://github.com/domsson/fakesteak" class="external" target="_blank"
-rel="noopener noreferrer">Fakesteak</a>. 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)
@@ -70,50 +89,30 @@ 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."
+<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.
 
 Files: [source.tar.gz](source.tar.gz)
+