For my class' animation project, one common pattern that students choose is what I call '8-bit', where they can design sprites in excel with conditional formatting, export the csv to Snap!, and write custom blocks to iterate through the table of pixel color codes and draw each pixel as a short/wide/square 'line' (with flat line ends).
Redraw over and over in different positions, changing between a handful of sprites, and you've got a cool animation.
But this year, some of my students got overly ambitious on their sprite designs, and I didn't anticipate that we would run into (blow past) the limits of Snap!'s performance to render sprites this way with large numbers of pixels and/or many pixel color codes.
Here is a stripped down example of the largest/most complex of my students' sprites. Performance seems to vary a little depending on hardware or browser, but despite my best efforts to eliminate bottlenecks, it is still really too slow.
Can anybody see any inefficiencies I'm not thinking of, and find a way to speed this up 2x or better?
I can't look at the code right now because I'm on my phone, but I can give you some tips to draw pixel art at a good speed.
For every line, loop through the pixels finding how many of the same color are in a row, then draw that number of pixels in one move ((pixel width) * (number of pixels)).
Draw each bit of animation, then save the pen trails in a list. For example, before the game starts, draw the first frame, grab the pen trails, then save them to a list, or a dictionary marking the name. Then clear, and repeat for the rest of the costumes. To get the costumes, just find the costume, switch to that costume, go to the position, then stamp. This eliminates having to draw the sprite every single frame.
Thanks for the quick responses -- even without seeing, you've latched onto what we're doing very well
Run lengths is a great idea, I'm sure that would gain 2x at least. I'd have to think about whether I could expect my students to be able to code that, or maybe give them a block that computes a run-length version of a sprite given a flat array.
Pen trails -- whoa, I've never seen that before! So that would preserve pen up/down that we're currently using for transparent pixels? And then the pixels would be pre-rendered in the costume, so stamp wouldn't have to go through all the original movements of the cursor?
I was able to test out the pen trails (scroll down in the embedded project), and it worked a treat! (in terms of speed, some adjustments need to be made to the positioning)
I think that is the answer; it's too late for this year, but I will include it in my plans for next year
I think run length (that's what it's called) is a relatively simple concept to understand, and it can be fun for a student to figure it out. Plus, each line is a list, so it wouldn't be too hard to look at each line. As for transparent pixels, just don't even draw them, only move.
yes transparent pixels when drawing everything out is clear (pun intended), I was worried that pen trails might capture transparent pixels as solid white, but no it's better than that!
The fact that this whole pen trails infrastructure exists tells me somebody else (bh?) had this problem before, and spent a lot of work coming up with this elegant but sophisticated solution
The pen trails block has been in snap ever since I joined, hich was 5.4. I'm assuming they added it so they can draw stuff and then save the costume. It's actually used in the text costumes library.
OK, does Snap! have any built-in or library utilities to access kv pairs like a hashmap, faster than linear lookup?
Also, can pen trails be used to set the stage to a fixed image? I was able to help students make a static background permanent with right-click/pic... on the stage and then upload that image as a Stage/Backgrounds, but all within Snap! would be better.
I guess Stage/Backgrounds is really just sprite-named-stage/Costumes and works the same way?
You actually can type text into the item of block for it. There is also a block in the list utilities library (assoc) which does achieve it. The assoc is good if you have keys that are numbers. The assoc block is a linear lookup, but it's actually very fast.
Yes, since the pen trails is a costume, you can tell the stage to switch to the pen trails costume (background is just another word for costume).