This is cool... But I feel like having different color/brightness for each symbol kinda defeats the purpose of it being ASCII when the symbols only correspond to different intensities anyway.
Just throwing a HELL YES <with a kung fu punch> out there for this. Nice work. I've been trying to integrate a live ascii video feature for a while now and the subtle detail on this is really inspiring.
Neat. It'd be more "ASCII" if it used 8x16 pixel (but right extended to 9x16) characters in 80:133 width:height aspect ratio since 80x25 characters at 720x400 on 4:3 results in 80:133 pixels. An arbitrary sized canvas is cool so long as the aspect ratio is preserved.
The infamous MCGA/"VGA" mode 13h had pixels with an aspect ratio 6:5, while 320 x 240 Mode X was square (1:1).
I still remember the unchained offset calculation for the memory offset for pixel memory access before the era of U and V pipes and many optimizing compiler passes:
https://post-processing.tresjs.org/guide/pmndrs/ascii
https://forum.babylonjs.com/t/ascii-shader-using-glsl-postpr...
https://threejs.org/examples/?q=ascii#webgl_effects_ascii
https://fwdapps.net/l/asci/
https://codesandbox.io/p/sandbox/ascii-postprocessing-n628p8...
https://www.youtube.com/watch?v=NxeRcnLr0ko
and the code: https://github.com/kristopolous/ascsee
I just updated it so it compiles on modern systems.
I also found the original version if you like being an archaeologist: https://9ol.es/tmp/gol.c
The infamous MCGA/"VGA" mode 13h had pixels with an aspect ratio 6:5, while 320 x 240 Mode X was square (1:1).
I still remember the unchained offset calculation for the memory offset for pixel memory access before the era of U and V pipes and many optimizing compiler passes:
In real-mode (linear): 0xa0000 + (320 * y) + x