This is such a great article! I found myself thinking, “I wonder if some of this could be used to playback video on old 8-bit machines?” But they’re so underpowered…
Might checkout what people have done on the 6502 in an Apple II.
ASCII characters are not pixels: a deep dive into ASCII rendering
91–100 of 158 posts
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#92really great! adjacent well-done ASCII using Braille blocks on X this week:
nolen: "unicode braille characters are 2x4 rectangles of dots that can be individually set. That's 8x the pixels you normally get in the terminal! anyway here's a proof of concept terminal SVG renderer using unicode braille", https://x.com/itseieio/status/2011101813647556902
ashfn: "@itseieio You can use 'persistence of vision' to individually address each of the 8 dots with their own color if you want, there's some messy code of an example here", https://x.com/ashfncom/status/2011135962970218736
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#93> The image of Saturn was generated with ChatGPT. Wait...wh...why?!? Of all the things, actual pictures of the planet Saturn are readily available in the public domain. Why poison the internet with fake images of it?
> > The image of Saturn was generated with ChatGPT.
> Wait...wh...why?!?
It has just begun. Wait until nobody bothers using Wikipedia, websites, or even one day forums.
This is going to eat everything.
And when it's immediate to say something like, "I need a high contrast image of Saturn of dimensions X by Y, focus on Saturn, oblique angle" -- that's going to be magic.
We'll look at the internet and Google like we look at going to the library and grabbing an encyclopedia off the shelves.
The use of calculators didn't kill ingenuity, nor did the switch to the internet. Despite teachers protesting both.
Humans will always use the lowest friction thing, and we will never stop reaching for the stars.
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#94Great article! I think there's a small problem with intermediate values in this code snippet: const maxValue = Math.max(...samplingVector) samplingVector = samplingVector.map((value) => { value = x / maxValue; // Normalize value = Math.pow(x, exponent); value = x * maxValue; // Denormalize return value; }) Replace x by value.
Just pushed a fix, should be live in a minute or two, thanks again!
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#95Fantastic article! I wrote an ASCII renderer to show a 3D Claude for my Claude Wrapped[^1], and instead of supersampling I just decided to raymarch the whole thing. SDFs give you a smoother result than even super sampling, but of course your scene has to be represented with distance functions and combinations thereof whereas your method is generally applicable. Taking into account the shape of different ASCII charact…
Looks very cool! Thanks for sharing.
The resulting ASCII looks dithered, with sequences like e.g. :-:-:-:-:. I'd guess that it's an intentional effect since a flat surface would naturally repeat the same character, right? Where does the dithering come from?
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#96Quite amazing breakdown, thank you!
I'm hoping people who harness ASCII for stuff like this consider using Code Page 437, or similar. Extended ASCII sets comprising Foreign Chars are for staid business machines, and sort of familiar but out of place accented chars have a bit of a distracting quality.
437 and so on taps the nostalgia for BBS Art, DOS, TUIs scene NFOs, 8 bit micros.... Everything pre Code Page 1252, in other words. Whilst it was a pragmatic decision for MS, it's also true that marketing needs demanded all text interfaces disappeared because they looked old. Text graphics, doubly so. That design space was now reserved for functional icons. A bit of creativity went from (home) computing right there and then. Stuffing it all into a separate font ensured it died.
But, that stuff is genuinely cool to a lot of people in a way VIM, (for example) has never been and nor will it ever. This is a case of Form Over Function. Foreign chars are not as friendly or fun as hearts, building blocks, smileys, musical notes, etc.
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#97It would be interesting to see how things changed if you included extended ascii characters [1], which were widely used for ascii UI. [1] https://www.lookuptables.com/text/extended-ascii-table
I did actually try out various alphabets e.g. Cyrillic, Greek and symbols (e.g. box drawing symbols), but ended up removing them: https://github.com/alexharri/website/commit/d969ef839
Using only ASCII felt more in the "spirit" of the post and reduced scope (which is always good)
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#98Great work! While I was building ascii-side-of-the-moon [0][1] I briefly considered writing my own ascii renderer to capture differences in shade and shape of the Lunar Maria[2] better. Ended up just using chafa [3] with the hope of coming back to ascii rendering after everything is working end to end. Are you planning to release this as a library or a tool, or should we just take the relevant MIT licensed code from…
The ASCII moon tool is fun to play around with!
No plans to build a library right now, but who knows. Feel free to grab what you need from the website's code!
If I were to build a library, I'd probably convert the shaders from WebGL 2 to WebGL 1 for better browser compatibility. Would also need to figure out a good API for the library.
One thing that a library would need to deal with is that the shape vector depends on the font family, so the user of the library would need to precompute the shape vectors with the input font family. The sampling circles, internal and external, would likely need to be positioned differently for different font families. It's not obvious to me how a user of the library would go about that. There'd probably need to be some tool for that (I have a script to generate the shape vectors with a hardcoded link to a font in the website repository).
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#99It would be interesting to see how things changed if you included extended ascii characters [1], which were widely used for ascii UI. [1] https://www.lookuptables.com/text/extended-ascii-table
I did actually try out various alphabets e.g. Cyrillic, Greek and symbols (e.g. box drawing symbols), but ended up removing them: https://github.com/alexharri/website/commit/d969ef839 Using only ASCII felt more in the "spirit" of the post and reduced scope (which is always good)
[deleted]
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#100It's important to note that the approach described focuses on giving fast results, not the best results. Simply trying every character and considering their entire bitmap, and keeping the character that reduces the distance to the target gives better results, at the cost of more CPU. This is a well known problem because early computers with monitors used to only be able to display characters. At some point we were ab…
You said “best results”, but I imagine that the theoretical “best” may not necessarily be the most aesthetically pleasing in practice. For example, limiting output to a small set of characters gives it a more uniform look which may be nicer. Then also there’s the “retro” effect of using certain characters over others.
> limiting output to a small set of characters gives it a more uniform look which may be nicer
And in the extreme that could totally change things. Maybe you want to reject ASCII and instead use the Unicode block that has every 2x3 and 2x4 braille pattern.