For prior related work, check out patent US-6377261-B1 "Compiling glyphs into instructions for imaging for execution on a general purpose computer" filed 1996. The basic idea is each character turns into a sequence of "Load Immediate" / "Shift" / "OR to Memory" instructions; so there's no more fetching from a stored bitmap of the font, as the pixels are implicit in the Immediate data in the generated machine code. Then you can get fancy when one row of pixels is the same as the previous row in the character, so you don't even need to do the Load Immediate. Etc. This scheme was used in FrameMaker for Macintosh back in the day, as implemented by Gus Fernandez (who went hog wild on additional optimizations).
Image 6 (with figures 8 through 12) is fun; you can eliminate the Shift if you're willing to have multiple different JITed functions for each character, each one generated knowing what its shift count is, leading to yet more optimization opportunities.
Something like this was called "sprite compilation" and used a lot in the DOS game coding scene back in the day. The idea was, given a bitmap image of a sprite, produce the code that would draw that sprite on the screen in assembly and incorporate it into your game. Not very flexible, but fast and useful in the days when games had a lot of 2D bits and bobs moving around, especially for those who could not yet afford a 486 and were stuck on an old Tandy 1000 or something...
I've been building BASIC32, a retro BASIC interpreter for microcontrollers so I can flash it once and easily create lots of new projects.
What you give up with the authors approach is "read". The screen becomes write-only. There are only a few functions that require reads: getting a pixels current color and doing operations like flood fills or paints.
Because I was going for the retro feel of BASIC, I wanted to support these, so I opted for a frame buffer. It isn't as technically cool. On the RP2350, it does require low resolution and low bit rates because they often have RAM limited to KB.
If you step-up to the ESP32-S3 variants with 4MB or 8MB of RAM the frame buffer gets much easier.
This is cool, I did something similar with a CoreText replacement I've been building recently.
My code can JIT + render to the atlas faster at p100 than CoreText can render without the JIT at p50, and with better quality (measured against an exact cover reference).
For prior related work, check out patent US-6377261-B1 "Compiling glyphs into instructions for imaging for execution on a general purpose computer" filed 1996. The basic idea is each character turns into a sequence of "Load Immediate" / "Shift" / "OR to Memory" instructions; so there's no more fetching from a stored bitmap of the font, as the pixels are implicit in the Immediate data in the generated machine code. Then you can get fancy when one row of pixels is the same as the previous row in the character, so you don't even need to do the Load Immediate. Etc. This scheme was used in FrameMaker for Macintosh back in the day, as implemented by Gus Fernandez (who went hog wild on additional optimizations).
Permalink: https://patents.google.com/patent/US6377261B1/en
Image 6 (with figures 8 through 12) is fun; you can eliminate the Shift if you're willing to have multiple different JITed functions for each character, each one generated knowing what its shift count is, leading to yet more optimization opportunities.
Since he's not caching the JITted code anyway, might as well!
Something like this was called "sprite compilation" and used a lot in the DOS game coding scene back in the day. The idea was, given a bitmap image of a sprite, produce the code that would draw that sprite on the screen in assembly and incorporate it into your game. Not very flexible, but fast and useful in the days when games had a lot of 2D bits and bobs moving around, especially for those who could not yet afford a 486 and were stuck on an old Tandy 1000 or something...
I've been building BASIC32, a retro BASIC interpreter for microcontrollers so I can flash it once and easily create lots of new projects.
What you give up with the authors approach is "read". The screen becomes write-only. There are only a few functions that require reads: getting a pixels current color and doing operations like flood fills or paints.
Because I was going for the retro feel of BASIC, I wanted to support these, so I opted for a frame buffer. It isn't as technically cool. On the RP2350, it does require low resolution and low bit rates because they often have RAM limited to KB.
If you step-up to the ESP32-S3 variants with 4MB or 8MB of RAM the frame buffer gets much easier.
Added "race the beam" to my personal dictionary today :-). It's such a breath of fresh air to read something which is not written by an LLM.
You might find this[0] interesting.
[0]: https://mitpress.mit.edu/9780262539760/racing-the-beam/
Link is to a book recommendation, "Racing the Beam: The Atari Video Computer System" $27 paperback.
This is cool, I did something similar with a CoreText replacement I've been building recently.
My code can JIT + render to the atlas faster at p100 than CoreText can render without the JIT at p50, and with better quality (measured against an exact cover reference).