Porpoise, chibicc & particles

The v0.7.2 version sees a rewrite of the default ship program and adds particle effects.

Recently, I found a fork of chibicc (a tiny C compiler) that retargets it to transpile C code to uxntal. After making sure that it could emit code against emulators whose devices don’t conform to varvara (the mainline emulator for uxn), I set out to rewrite the ship program manatee (written in uxntal) into another one called porpoise (written in C).

It may be strange to hear that it seemed like I just had to reproduce the previous code, because the philosophy of programming in concatenative languages such as Forth says that if you are writing the imperative structures as you would in C (essentially transpiling a mental image by hand), you are doing it wrong. My impression is that in this case, that advice boils down to not ignoring the stack in how you think about and how you implement your program (as the hypothetical C programmer who would store every value in memory). It really makes me curious how the people familiar with Forth would have approached the task that I have here (parsing text commands).

I’m not sure if it’s indicative of anything, but it seems that size of the original version’s assembly was 3552 bytes, and the rewrite came out to be 5049 bytes (grain of salt necessary, as they may not be equivalent in function) while I was thinking about the task in a similar way when I wrote the original version. That roughly corresponds to the size increase I saw when I tried transpiling the mandelbrot demo.

If you can put up with the increase in the size of the rom and the extra complexity that a small subset-of-C compiler requires, I think there’s a good argument for writing spaceship programs in C instead of uxntal, or any other high(er) level language that isn’t difficult to transpile to uxntal. The main thing I learned during this rewrite is that even if I try to indent and comment uxntal code, my brain wastes many cycles in decoding the structure I laid out every time I have to read it. Being forced to think in lower-level mechanisms introduces a mental overhead for me that is hard to ignore. Purely subjectively, it also felt less fussy and error-prone to write C, where I had a much better idea about the correctness of the code just by reading it. One feels like throwing nuts and bolts together to see what works, and the other feels more like doing clockwork surgery. That said, I still find it really cool that it’s possible to write these programs with nothing but an uxntal assembler.

After all this, I wanted to stretch a little with some graphics programming, for the sake of visual variety. Particles seemed like a well-separable system that could add some texture to the previously flat background. Basically, I only had to generalize the existing ECS slightly, define a few components for particles, and then render them with the sprite renderer. After I got up to the point where I could render some cosmic wind gently blowing some faint particles around, I went on to add a few other effects, around stars, ships, oases, monoliths and wormholes.

Other notes:

• fixed the background not being cleared to the background color
• added mass to stellar bodies (currently only used for particles)
• clients receive acceleration as it is now reset after synchronization