A similar technique could probably be used here.
ASCII characters are not pixels: a deep dive into ASCII rendering
151–158 of 158 posts
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#152Earlier quoted context omitted.
Surprised you didn't include the output result for the test image as a showcase of the library's results. Edit: nvm, confused by the libraries purpose. Thought it was primarily character based rendering focused based on the subject under discussion.
Sorry for the confusion. The use-case is a little difference because the goal is to display the image as close to the original as possible with the limitation of only being able to use a forground color, background color and character per cell. The character is selected based on it's shape just like in the article. So if you get rid of the colors in Chafa you end up with something similar to the article. That's what…
[1] https://en.wikipedia.org/wiki/List_of_8-bit_computer_hardwar...
Note: If you happen to know how to do multi-color dithering with some of these that would actually make significant improvements on some of these old picture hardware tests.
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#153Earlier quoted context omitted.
I want to do game programming again like it's 1999. No more `npm i` or "accept all cookies" :/ rant off :)
Go make a game for the Sega Genesis https://mdengine.dev/ Or, the GameBoy Advance https://github.com/GValiente/butano
Or the Super Nintendo Entertainment System https://github.com/alekmaul/pvsneslib
Or the Gameboy / GBC, Sega Master System, Gamegear, Nintendo Entertainment System https://github.com/gbdk-2020/gbdk-2020
Or the TurboGrafx-16 / PC Engine, Nintendo Entertainment System (alt), Commodore 64, Vic-20, Atari 2600, Atari 7800, Apple II/IIe, or Pet 2001 https://github.com/cc65/cc65
Or the ZX Spectrum, TRS-80, Apple II (alt), Gameboy (alt), Sega Master System (alt), and Game Gear (alt) https://github.com/z88dk/z88dk
Or the Fairchild Channel F https://channelf.se/veswiki/index.php?title=Main_Page
Note: Some are slightly pre-1999 (all these, I have at least successfully made a "Hello World" with)
----------------
If they're really wanting 1999, that's the 5th to 6th generation console range with Sega Saturn, PlayStation, Nintendo 64, and Dreamcast. (on these, only recommendations, no successful compiled software)
Playstation is really challenging and remains so even in 2026. Lots of Modchip and disk swap issues on real hardware. Possibilities: https://www.psx.dev/getting-started and https://github.com/Lameguy64/PSn00bSDK
N64 is less horrible, and there's quite a few resources: https://github.com/DragonMinded/libdragon and https://github.com/command-tab/awesome-n64-development
Sega Saturn is still pretty difficult. However, there is: https://github.com/yaul-org/libyaul?tab=readme-ov-file and https://github.com/ReyeMe/SaturnRingLib plus the old development kits from the 90's are still around https://techdocs.exodusemulator.com/Console/SegaSaturn/Softw...
Dreamcast is similar to the Saturn situation, yet strangely, a little better. There's https://github.com/dreamsdk/dreamsdk/releases and https://github.com/KallistiOS/KallistiOS along with the official SDKs that are still around https://www.sega-dreamcast-info-games-preservation.com/en/re...
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#154Earlier quoted context omitted.
Sorry for the confusion. The use-case is a little difference because the goal is to display the image as close to the original as possible with the limitation of only being able to use a forground color, background color and character per cell. The character is selected based on it's shape just like in the article. So if you get rid of the colors in Chafa you end up with something similar to the article. That's what…
Cool, and thanks for the explanation. Gotten interested in retro software recently, so may actually be helpful for trying to set up pictures in some of the retro consoles. Most do tend to be limited to foreground / background. The stuff listed here [1] is pretty representative of what's being dealt with. [1] https://en.wikipedia.org/wiki/List_of_8-bit_computer_hardwar... Note: If you happen to know how to do multi-co…
But maybe I didn't understand your real problem yet
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#155Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#156Earlier quoted context omitted.
Cool, and thanks for the explanation. Gotten interested in retro software recently, so may actually be helpful for trying to set up pictures in some of the retro consoles. Most do tend to be limited to foreground / background. The stuff listed here [1] is pretty representative of what's being dealt with. [1] https://en.wikipedia.org/wiki/List_of_8-bit_computer_hardwar... Note: If you happen to know how to do multi-co…
Isn't your problem more about Color quantization than about dithering? If you have big character cells like in a terminal dithering won't help you much. For each cell you want to find the best shaped cell and a foreground and background colour that are the closest to a colour from the supported palette. But maybe I didn't understand your real problem yet
However, for many the result is that the color choices are akin to a posterization filter in photoshop, where the nearest color is simply chosen. Often, there's actually the freedom 'available' to define a character set and choose at least a background / foreground color, with some kind of dithering pattern.
Sometimes the character set that can be defined is limited, so it has to be chosen carefully. Yet there's improvement from a 'large blobs of color' poster result to a smooth dither tone change.
The problem with the quantization result, is it just snaps to the 'nearest'. So even for relatively large areas of slowly gradiating color, if you only have one 'nearby' color, everything inbetween just snaps to that single color choice. You might have red, with slowly increasing green / yellow, yet it will always just snap to solid red.
This example from the Vic-20 kind of shows that issue. Large areas where it posterizes severely.
https://upload.wikimedia.org/wikipedia/commons/3/32/Screen_c...
Dithering suggested is something like this (greyscale example) except with choosable foreground / background (maybe 3-4, although less frequently)
https://araesmojo-eng.github.io/images/GreyScale_Dithering.p...
This example from the Vic-20 game Tutankarman shows that kind of approach. Varying amounts of dither and color used in dithing give the impression of changing skin tones.
https://www.neilhuggett.com/vic20/tutankarman03.png
They're both the Vic-20
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#157Amazing post, I didn’t think this through a lot, but since you are normalizing the vectors and calculating the euclidean distance, you will get the same results using a simple matmul, because euclidean distance over normalized vectors is a linear transform of the cosine distance. Since you are just interested in the ranking, not the actual distance, you could also consider skipping the sqrt. This gives the same ranki…
It's stuff like this I would have loved to know when I was doing game engine dev in the 90s.
So it was a known thing...