From 1d381196d88eb805041a80b42bc2fa2a44412589 Mon Sep 17 00:00:00 2001 From: soaos Date: Thu, 2 Oct 2025 17:25:46 -0400 Subject: Finish GPU text article --- blog/terminal_renderer_mkii/index.html | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) (limited to 'blog/terminal_renderer_mkii/index.html') diff --git a/blog/terminal_renderer_mkii/index.html b/blog/terminal_renderer_mkii/index.html index 78171f1..3c94df4 100644 --- a/blog/terminal_renderer_mkii/index.html +++ b/blog/terminal_renderer_mkii/index.html @@ -3,7 +3,10 @@ - + Terminal Renderer Mk. II - Rendering to Text with Compute + + + @@ -17,14 +20,15 @@
-

Terminal Renderer - Rendering to Text with Compute

+

Terminal Renderer Mk. II - Rendering to Text with Compute

October 2, 2025

This week I brought my terminal renderer to the next level by performing text rendering on the GPU.

-
The Stanford Dragon, outlined and rendered as Braille characters in a terminal emulator. +
The Stanford Dragon, outlined and rendered as Braille characters in a terminal emulator. +Full video
@@ -117,7 +121,7 @@

The old way™

My first attempt at realtime terminal graphics with ordered dithering - (I put a video up at the time) + (I put a video up at the time) ran entirely on the CPU. I pre-calculated the threshold map at the beginning of execution and ran each frame through a sequential function to dither it and convert it to Braille characters. @@ -133,7 +137,7 @@ add outlines to objects, I was able to significantly improve the visual fidelity of the experience. A good example of where the renderer was at until like a week ago can be seen in this video. + href="https://tv.soaos.dev/w/9Pf2tP3PYY5pJ3Cimhqs9x" target="_blank">this video.

Until now I hadn't really considered moving the text conversion to the GPU. I mean, GPU is for @@ -167,12 +171,13 @@ I used UTF-32 encoding on the storage buffer because I knew I could easily convert a "wide string" into UTF-8 before printing it, and 32 bits provides a consistent space to fill for each workgroup in the shader versus a variable-length - encoding like UTF-8. + encoding like UTF-8. Here's a video of the new renderer working. Although now that I think about it, I could probably switch to using UTF-16 since all the Braille characters could be represented in 2 bytes, and that would be half the size of the UTF-32 text, which is half empty bytes anyways.

-

Okay so I went and did that, seems to work great. Wow. This little side quest has been a part of my +

+ Okay so I went and tried that but remembered that shaders only accept 32-bit primitive types, so it doesn't matter anyways. This little side quest has been a part of my broader efforts to revive a project I spent a lot of time on. I'm taking the opportunity to really dig in and rework some of the stuff I'm not totally happy with. So there might be quite a few of this kind of post in the near future. Stay tuned. @@ -181,4 +186,4 @@ - \ No newline at end of file + -- cgit v1.2.3