Long Program Code = Slowed Rendering?

Help with Snap!
1

old 4x4 file: https://snap.berkeley.edu/project?user=mike%20lee&project=pixelAnimationCreator4x4
new 6x6 file: https://snap.berkeley.edu/project?user=mike%20lee&project=pixelAnimationCreator6x6
I finished creating the "Pixel Animation Creator 4x4" program with additional time so I upgraded my program to project 6x6 pixel animation. However, when I tried to run the animation, the blocks were all going out of order, so I had no choice but to increase the time. Is it because of the long programs that the program should run through or is it because of another reason? Also, the 4x4 version of the program was also having a problem with loading the animation.
p.s. currently, I am having a hard time running SNAP with google chrome, so I'm temporarily using firefox to run my program.

2

Interesting project. And yes, that's a lot of code and a lot of variables. Two things that I think will help:

  1. Have one pixel sprite and make 35 clones of it when the program starts. That way, there's only one copy of the code. Instead of global variables with the name of a pixel as part of their name, just have one sprite-local variable that will be duplicated in the clones but each clone (i.e., each pixel) can have a separate value.

  2. Instead of a variable (per pixel) per frame, use a list to hold the state of the pixel in each frame. So now you're down to one local variable per clone, and the value of the variable is a list whose length is the maximum frame number.

So the only global variables will be ones that really are global in purpose, such as "maximum frame". (And you should turn that watcher into a slider!)

3

with a list, you can have unlimited frames and you can even store all the variables in one list, and lists in a list, so you can have only 1 variable for the animation, and 1 variable to the maximum number of frames.

4

Sure, in principle you only ever need one variable altogether, because you can cram all the other ones into a list. (Actually, if you squint your eyes just right, that is how it works; the variable is called "memory.") The goal is to organize your data in a way that's both reasonably elegant and reasonably efficient. Since a pixel doesn't need to know what the other pixels are doing (unlike, for example, in a Game of Life program) there's no need for global variables or a global list here.

5

I wasn't saying there needed to be a global variable or list

6

But you said

Did you not mean a single list of lists for all the pixels?

7

yeah

8

There is remix of a project slightly simplified

https://snap.berkeley.edu/project?user=dardoro&project=pixelAnimation%20v2

Main changes:

  1. Editor as arrays of clones
  2. Arbitrary number of "colors" - every costume of "blockOne"
  3. Frames stored as costume of "sprPreview" sprite
  4. Live preview of animation
  5. Created animations can be exported/imported as xml from "sprPreview" sprite

Costumes are quite big. They are created from "pen trails".