Live data from Hacker News

ASCII characters are not pixels: a deep dive into ASCII rendering

alexharri.com

151–158 of 158 posts

Re: ASCII characters are not pixels: a deep dive into ASCII rendering

#151
I did something similar to use images in a mosaic, and taking the image contents into consideration. This turns out is super-simple as long as you do everything in JPEG space: Just use however many coefficients to compare! So, scale the original image to have 8x8 pixels per "image pixel" in the final output, and then scale every candidate to 8x8. Now just compare the DCT coeffs directly!

A similar technique could probably be used here.

Re: ASCII characters are not pixels: a deep dive into ASCII rendering

#152
post #134

Earlier 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…

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-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

#153

Earlier 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 an alternative for the Sega Genesis https://github.com/Stephane-D/SGDK

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

#154
post #152

Earlier 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…

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

Re: ASCII characters are not pixels: a deep dive into ASCII rendering

#156
post #152

Earlier 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

Agree in the case of large character cells like a terminal. For those cases, where you only have something like 40x48 in the Apple II Low Res mode, there's only so much you can do with the limited resolution.

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

#157

Amazing 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.

I mean we used dist^2 all the time for comparisons in our game engine back in the 90s (multiple different engines actually).

So it was a known thing...

Post reply on HN