Thinking out loud
Things can look like they’re going to work really well, and then just don’t.
This is also tomorrow’s lesson.
Case in point:
I tried to give each pixel of the trail a different acceleration curve, so that they trail behind and (later) fade out.
Mixed results. The different acceleration curves for the pixels mean that they change relative distances between each other, which reads as weird jitter.
More work needed.
I made the changes to the Witch Lights animation from last night, and am happy with the progress so far. It's not done, but progress is being made.
This is a big improvement. Interestingly, on my other computer, the keyboard repeat rate is faster, which results in a higher framerate. That's making a big difference in the effect of the animation.
In this video above, the sprite appears to accelerate a bit too quickly, and then when it stops short, the tail isn't long enough.
Above, I adjusted the frame rate down (by using the keyboard control panel), and now the speed of acceleration and braking seem ok. But, when the sprite stops short, the tail doesn't shrink from the left quickly enough.
So: framerate is a variable to control for.
I have to upload my code to the Witch Lights development board and watch the actual animation on the NeoPixels to see what kind of framerate I'm getting.
So, next actions:
Connect development Arduino to my mac and upload the current code
Connect a simple push-button up to the sensor pin on the Arduino to simulate the motion sensor
Take the 5-meter cheapo NeoPixels I just got from AliExpress and connect them to my NeoPixel strip test rig, which will verify that the pixel strip is good
Hook the (hopefully good) pixel strip to the development board, and power it on. If everything is good, I'll see a pride-flag test pattern
Test the current known-good code with the push button, verify that it triggers sprite object creation and animation
Create a new Animation Test Sprite class, copying the current Sprite object class, and tell the motion sensor objects to trigger generation of that class, not the default class
Export the animation to CSV from Excel
Run the csv2cpp python script on that CSV file and copy the generated code
Insert the generated code into the appropriate segment of the Witch Lights Arduino sketch, and compile/upload the code to make sure nothing breaks.
Modify the Animation Test Sprite class so that in Scanner mode, it looks at the array of strings tagged with the animation name.
Also change the global variables for animation frame width and animation frame count (create new globals for now, refactor this later)
Compile and upload the code, which -- in theory -- should result in the Witch Lights animating my new sprite animation when I hit the go button.
Simple.
Later, I'll work out a master class for sprites with different animations, and make all the different animation sprites children of that, but for now it's gonna be messy.
Because the point is to see the framerate of the animation on the Arduino and NeoPixels.
And then I'll adjust the framerate on my computers (by messing with Keyboard preferences) to match as closely as possible.
What a horrible hack this is. I'm absurdly proud.
So now it's down to pixel animation basics. How, in this format, do you animate a classic "skid-stop"?
It appears to be about timing.
This is my surprised face.
In the above, my intent was to show the sprite skidding to a halt, flattening out as a result of that, and the tail flying past the sprite, stretching out to the right a bit, and then snapping back, like the ears on a cartoon dog flapping forwards when it skids to a halt.
The sprite skids to a halt, but then keeps going a bit. I need to make the halt more abrupt. The timing of the tail's expansion and inversion don't match up.
In the second video below, it's better. But still room for improvement.
The good: speeding up the braking helped.
The less good: need to work on the timing of the tail collapsing and following through.
It's too languorous, and the motion doesn't look linked to the bright lead sprite's sudden stop. The impression is not of mass moving with inertia, but a mechanical emanation.
The stop itself could be sped up a bit further, it's still a little slow.
The point where the tail starts going off to the right needs to be right as the bright sprite compresses and stops. Right there around row 14 or 15.
And the trailing lights need to shrink as soon as the brakes are hit and the sprite starts decelerating. So right there around 11 or 12.
You really have to go at this via trial and error, draw something that looks right, test it, and analyze where exactly it isn't meeting your vision. Writing about it here helps.
So the plan is, create at least one intro (in this case "braking") animation, and one "acceleration" animation, each of which will have to also return an integer for how many pixels per frame the sprite is moving at the end, so that it can hand off easily to the standard "travel" code.
When the sprite reaches its designated target pixel in travel mode, it switches from "travel" to "scanner" mode. It then needs to run the intro animation, and then hand over to the loop animation, which will start and end on the same pixels as the intro and outro animations, to make life easier.
The loop animation will run a certain number of times (right now, we use a random number between two constant values defined at the top of the sketch), and then exit and hands over to the outro animation.
The outro animation will (again) start on the same pixel as loop animations end on, so will accelerate the sprite away, ending on a target pixel for hand-off to "travel" mode.
That's the rough plan, anyhow. We will see how it goes.
