James Fenn @james@is.a.horrific.dev

Got around to publishing the JVM & Android targets for my multiplatform git REST API wrapper. I ran into a bit of trouble publishing specific build variants, but my poke-it-until-it-works development methodology appears to have succeeded!

Next on the agenda, I'll be implementing some form of request caching and improving its error logs...

https://code.horrific.dev/james/git-rest-wrapper

I did learn that, while Kotlin's `sequence` utility is very cool, it is *not* just a sequential Iterator! They can actually be executed multiple times, which caused some really weird bugs in my parser.

Good news: there's an `iterator` function that is! https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.sequences/iterator.html

I'm using this to effectively parse the document *during* iteration - so the implementer can do an early return or discard extra nodes without parsing the entire file.

(I'm sure other parsers already do this with far more efficiency - I'm just reinventing wheels for fun!)

I started writing a Kotlin implementation of https://kdl.dev last week (for no specific reason) and it's actually *really fun* to work on! Admittedly, it has been a while since I enjoyed working on something this much.

https://code.horrific.dev/james/kdl-kt

Interesting CSS hack I wrote this week: apparently some elements are rendered differently during a transition - I noticed it as a small "jiggle" on my site's nav icons... (setting "backface-visibility" to "hidden" on the transformed element prevents the jitter)

I suppose the browser doesn't know when the back of an element is visible if animating a transform property, but does in a static position? (causing the jitter when it starts/ends)

Anyway, I have smooth un-jittery nav icons now. Just in case anyone was wondering how I did that.

(I know this seems trivial, but you have no idea how long I'd been searching for this fix - really, CSS is hard)

So it turns out programming is kinda hard! (lol)

In good news, though, all these mistakes have actually paid off, and my snake game can now run at about 30fps (that's twice what I had before!) - as long as I avoid any big light sources.

- I forgot to include a comma when adding arguments to a function, accidentally subtracting two numbers and making random parts of the background disappear. (3/3)

(It's nice having direct visual feedback for all my mistakes - makes these bugs a lot more interesting to find!)

- I wrote some code to keep track of chunk updates and reuse old data to avoid light-tracing on each frame, and used the wrong position value to index them with. (2/3)

This caused *no updates* to occur, drawing light maps on top of each other and creating this horrible mess:

I've been collecting a few of the more interesting ways I've broken my snake program so far:

- I forgot to replace the arithmetic operators on my Vector types (now an alias of a Long), causing an overflow error and making the snake sever its head. (1/3)

https://www.twitch.tv/videos/922598507

It's a bit annoying that - even in this simple example scene - I'm already reaching the limits of what Java can do in ~60ms (the amount of time I have to draw a frame)

I'm having to pedantically limit the amount of new object allocations and everything, just to get a mere 15fps.

This is why, on Android, the IDE warns against constructing new objects in the View.draw / onDraw functions: they provoke the garbage collector which can create a massive stutter as it pauses the entire application to free up memory space.

To be fair, my issue could also be "I've written poorly optimized lighting code that iterates over every pixel in the radius of each light and traces back to its source to determine the intensity"...

Nah, it couldn't be *my* code that's the problem, let's blame the JVM!

I've gone back to my hacky pixel game engine to write a strange wavy snake game and it... sort of works?

Still have a lot of random bugs/performance issues to work out, but this is a lot of progress from what I had the last time I worked on it.

I recently regained some of my motivation to work on software things - in the form of Java's MIDI APIs! I've been intermittently working on a Kotlin library for writing "music applications" (whatever that means) with Asynchronous Flows: https://jfenn.me/blog/2021-01-31-Audio-Automation/

It sort of seems like Flows aren't really meant for this, but funnily enough, it actually works *really well* - the format of `metronome(500).take(3).transform(...)` (and all the other Flow functions) is very intuitive to use in this manner.

I'm hoping to integrate this with something a bit more interactive, but the latency problems kind of prevent me from doing anything really time-sensitive with it. For now, I'm just focusing on the interface and maybe I'll find a better solution to that later.

I'm streaming again today! Me and Shane will be playing Minecraft... looking for yet more netherite to decorate our base. Join us at 8-11pm EST on https://twitch.tv/fennifith!

Corbin and Jahir are also streaming (something far more productive) right before me - go check out their work, too! https://twitter.com/crutchcorn/status/1341048159359946754

Well, using this program on my synthesizer definitely doesn't sound much like a Timpani, so it seems it isn't strictly adhered to, at any rate...

Why on earth does the General MIDI spec list Timpani as a "strings" instrument? Is there some critical feature of Timpani that I'm not getting here?

I've seen a drum once, I'm definitely qualified. This isn't right!

https://en.wikipedia.org/wiki/General_MIDI#Strings

Today I'm streaming some Minecraft with Corbin - we're looking for netherite, not throwing our diamond tools in lava, and more!

We'll be live until about 10pm (EST) - come hang out!

https://www.twitch.tv/fennifith
https://www.twitch.tv/crutchcorn