🔥 week 11, day 3 - rustwasm embers & qmk despair

hosted Creative Coding

prompts:

• coding prompt: bandwidth monitor
• situational prompt: I never meant this to happen
• oblique prompt: Discover the recipes you are using and abandon them
• random emoji: 🔥 🐾 🚞

Everyone immediately fixated on fire, which was fun. We had 8 people and ended up splitting into 2 groups, although I was kind of half soloing and half lurking on the Rust group, which made a terminal simulation of a very dry forest fire with 🔥 and 🪵 emoji.

some links to fire simulations I briefly perused for inspiration

• by zufalisgenerator: marching squares algorithm, cel-shaded appearance, html5 canvas
• by jason.today: modification on a pixel sand simulator
• by bsongit: very simple canvas-based pixel fire, Doom-inspired
• a 6.837 group final project writeup from 1999: volumetric raymarching of a particle system, Perlin noise, fractal functions for complex motion

rustwasm embers

Given the session timebox constraint of 1.5 hours, I decided to just fork my Rust-WASM game of life project and play around with tweaking the cellular automata behavior to look more fiery.

First, on the rendering side (JS), I just randomly colored the live cells with a palette of a few fiery colors.

Then on the game logic side (Rust), I tried tweaking the rules to look more fiery. Fire shouldn’t persist forever, it should burn out at some point, but I also didn’t feel like implementing a bunch of filler countdown states to give the state machine a notion of a timed burn. So I took a shortcut by making “live” (fire) cells die immediately with some probability, breaking determinism to make it look more chaotic. I also made fire “spread” more easily by letting “dead” (empty) cells come alive with fewer “live” neighbors.

This didn’t look at all like fire spreading through tinder, but it actually reminded me a lot of the shimmering of embers in a burned-down campfire.

I played around with some other configurations, including adding a third cell state “Fuel” that needed to be present for fire to spread. This looked more like fire eating through tinder from above, but I found it less satisfying to look at, so I reverted to the simple ember implementation for my presentation.

New machine things: hastily reinstalled ngrok so I could tunnel my local server to a publicly shareable link for people to play with.

qmk despair

I compiled my untouched keyboard firmware (after sweatily backing up all my previous copies of my correctly working firmware), and found that I was getting a lot of new bugs, seemingly due to QMK API updates that have rolled out since I last touched my firmware. So I went in to fix those to the best of my abilities with the documentation.

And now my trackpoint is unusably jittery, inexplicably triggering a mouselayer key each time I move it. I do not have the brain space to debug this at the moment and there are only two people in the world I can ask for help (I am currently one of three known people who has Frankenstein-hotswap-modded a Lenovo trackpoint onto a qmk keyboard, which is both a source of pride and a huge debugging obstacle), so I think I’ll revert to the old firmware for now.

The rewards/perils of compiling your own firmware for the very device you need to write code without pain. 🤣💀

closing microblogular notes

It’s funny that some of my microblog posts are a lot longer than many of my “official” blog posts. Let this be a microcosmic reminder that bigger is not intrinsically better, especially when it comes to the code world.

What you are seeing are my raw stream-of-consciousness dumps without the care I usually put into lovingly curating everything into a thoughtfully laid out and well-documented Socratic lesson, story, or reference page. This “microblog” should really be called “low-effort blog” or “public speed journal”, although that doesn’t sound as catchy.