Nice. This looks very similar to what I have implemented: https://www.npmjs.com/package/asciiground, but I intended it more as a library where a user could program their own patterns by extending the existing systems. Sadly, my GitHub account got flagged, so there is no way to access the repository or GitHub pages for the demo at the moment.
This looks like a good way to model "satellite-view clouds" where you render "the full atmosphere". I don't think it would work well when modeling "ground-view clouds" however. I have been looking for a good (fast) algorithm for doing that, would appreciate it if people have pointers for that.
Really like it, only thing some of the cells can be jittery and rapidly switch back and forth between two symbols, making for an unpleasant effect, maybe there is a way to smooth this?
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.
You can render only single characters. First you need to change the HTML "max" attribute of <input> to 1.1 in the "Glyph Thresholds". And set 0.0 for the desired characters and the characters above. Set 1.1 for the remaining characters.
For example, if you only want the dash, set the dot and dash to 0.0. Then set 1.1 for the plus, ring, and cross characters.
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:
unsigned short offset = (((y << 2) + y) << 6) + x;
unsigned char far *ptr = (unsigned char far*)MK_FP(0xA000, offset);
// IIRC: #define MK_FP(seg, off) ((void far *)((unsigned long)(seg) << 16 | (unsigned long)(off))) // far pointers != linear address
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
For example, if you only want the dash, set the dot and dash to 0.0. Then set 1.1 for the plus, ring, and cross characters.
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
https://srdjan.pro
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