Things accomplished:

Parabolic acceleration & braking curves for faerie sprites, implemented as a method

Recursive forced fade-from-dark-to-light algorithm when faeries stop and idle

New version of idle method which replaces CRGB pre-rendered pixel arrays with algorithm, one of a few experiments. This saves hugely on SRAM usage, allowing me to save that SRAM for pixel animation for special accents and looping travel animations.

There was much debugging.

I am pretty good at debugging. It’s basically how I approach the world.

Next up, what I want is for the sprites to travel long distances, idle, then do a random shorter move (like shown in the video below), idle, and repeat a few times.

It’s just adding another state bool to the class, and a bit of logic.

More concerning to me: when transitioning from idle to travel, there is a minor visual glitch, more obvious in person than in video.

It’s caused by the 3 pixels I’m manipulating suddenly changing state when UpdateIdle() calls StartTravel(). At that moment, 3 new entries from the same fixed colorArray are written to the CRGB that represent my pixel pattern.

I need a colorFade function to smoothly transition between two states. I’ve found example code. Fortunately, reading code and understanding what it does is also something I do decently.

Anyone reading this who might HAVE one already though for FastLED? Let me know please if so. 🙃

I have some secret ideas sketched in my lost notebook (🤬) that I was hoping to get to, but if I can just get this last faerie sprite checked in to GitHub I can turn my attention to other things that sorely need my attention.

Extra animations and things are luxuries, I’m going for minimum viable magic, so that my brain will relax and stop hyperfocusing on not having a viable product for the release date.

Considering making faeries more likely to stop and idle/flit around when they encounter other faeries. This requires collision detection. Have some sketches for that as well.

Which had all my notes on sprites under design.

I just copied down some from memory that aren’t code yet:

Here I’m using SRAM wisely; the same char pattern encoded for pixel brightness algorithms  can be used to display other effects. What effects exactly depends on experimentation. 

Turns out, the Arduino was not crashing at all. I just had a bug in the line of code that sends the current animation frame buffer to the function that writes to the LEDs.

Fixed that. And now I can see the many ways that this animation doesn’t work.