Pretty cool! - not just the visual, but also making the Espruino-Wifi with the .boot0 & 1 a Display/Application server.
What was the reason to use a black / light blocking grid versus a semi-transparent / partly light conducting grid? ...after all you used a diffuser anyway, as I think I understand.
Checked out the Fireplace and wondered what it would take to make the individual flames behaving randomly...
In the first conversation of the reaction game implementation I drive the LED string directly from the application data.
The second introduces a Graphics layer to a zig-zag display wired matrix to display just any thing.
In the third conversation I let the application draw to the graphics buffer thru the Graphics object's methods / functions and let the display update independently... (I did then also some work for translating areas within the graphics buffer for, for example, scrolling... more could be done there to also include more complex graphic operations... rotation, shrink, warp,... Efficiently moving things around in zig-zag Graphics buffer visualized w/ 24/32 bpp displays / neopixel strings, where for speed I use inline-C).
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Pretty cool! - not just the visual, but also making the Espruino-Wifi with the .boot0 & 1 a Display/Application server.
What was the reason to use a black / light blocking grid versus a semi-transparent / partly light conducting grid? ...after all you used a diffuser anyway, as I think I understand.
Checked out the Fireplace and wondered what it would take to make the individual flames behaving randomly...
Your application inspires me to modify this project about Reusing some RGB LED interior lighting modules and replace the single source with your multi source...
I'm sure you have seen these conversations:
In the first conversation of the reaction game implementation I drive the LED string directly from the application data.
The second introduces a Graphics layer to a zig-zag display wired matrix to display just any thing.
In the third conversation I let the application draw to the graphics buffer thru the Graphics object's methods / functions and let the display update independently... (I did then also some work for translating areas within the graphics buffer for, for example, scrolling... more could be done there to also include more complex graphic operations... rotation, shrink, warp,... Efficiently moving things around in zig-zag Graphics buffer visualized w/ 24/32 bpp displays / neopixel strings, where for speed I use inline-C).