summaryrefslogtreecommitdiffstats
path: root/_log
diff options
context:
space:
mode:
authorSadeep Madurange <sadeep@asciimx.com>2025-12-25 22:48:14 +0800
committerSadeep Madurange <sadeep@asciimx.com>2025-12-25 22:48:14 +0800
commit8147fb1110fd0037610de6701e83ccd29f4d0432 (patch)
tree7271f6fdfb0cc764fddcaef8e8ded2b3d1474ec3 /_log
parentd2c9a7b88adae1e949af60b7f276364592e49869 (diff)
downloadwww-8147fb1110fd0037610de6701e83ccd29f4d0432.tar.gz
Use the full post instead of the log for Matrix.
Diffstat (limited to '_log')
-rw-r--r--_log/matrix-digital-rain.md146
1 files changed, 129 insertions, 17 deletions
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.
-<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 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
+```
+
+<video style="max-width:100%;" controls="" poster="poster.png">
+ <source src="matrix.mp4" type="video/mp4">
+</video>
-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)