* Even though indexed PNGs (256 colors or less) don't seem to be supported in KS, grayscale PNGs work correctly and can be used for COs. If your sprite/animation doesn't need color, you can cut the file size to about a third of the original image by converting it to grayscale format instead of using RGB (since this color space only requires 1 byte per pixel, as opposed to 3-4 bytes in the RGB and RGBA formats).
* Using solid colors as much as possible is a good way to take advantage of the lossless compression in PNG, which is why I posterized the animation to B&W (since the original animation already used silhouetted graphics) in order to make it take as less disk space as possible. However, trying to optimize the palette in the resulting PNG file caused KS to stop recognizing it, so I had to work with the full grayscale "palette" even when I only needed two colors.
* Despite the very low file size of the resulting PNG files, trying to fit the entire animation into a single strip always resulted in the processing tool (ImageMagick) freezing and/or slowing the system down to a crawl due to high memory usage (again, probably because of the size of the decompressed data that has to be loaded in memory). The most I could manage without my system going completely haywire was making a 2000 frames long spritesheet, which took my PC a few minutes to build but worked just fine in KS. This might have been due to the low amount of RAM in my system (only 4GB), though, so maybe it's possible to make a single long strip if you have more than 8GB of RAM. Still, doing it that way is probably not a good idea, as this would make editing the resulting strips very slow and cumbersome (or even impossible).
* KS seems to stop loading spritesheets for COs after a certain amount of memory (about ~1.5GB) has been allocated to the
stdrt.exe process, resulting in a lot of blank/empty COs after said limit is reached. This is what happened when I was first experimenting with the 30fps version (probably due to the size of the raw uncompressed data for the entire animation), and my options were: A) shorten the duration of the entire sequence to about 1:30 by cutting entire segments; B) lower the resolution of the individual frames; or
cut down the frame rate from 30 to 15 fps discarding every other frame. I went with the last option, since I didn't want to use an incomplete animation nor resort to a smaller picture size.
* Since I couldn't fit the entire animation into a single strip, multiple COs had to be used. This wouldn't have been much of a problem in KS+ because I could have taken advantage of delayed shifts and the "block user" object to easily implement the entire sequence with only a few screens. However, doing this in vanilla KS was more difficult, since I could only delay screen transitions so much without requiring user intervention. What I did was making Juni loop through the entire screen (except the bottom row, which contains the Shift objects that make this possible) from the top-left to the bottom-right corner. I used a test animation (with an
Anim Speed value of 300, which seems to be the rough equivalent of 15fps) that displayed a numeric frame index so I could measure how many frames would be displayed per screen, and then used that value as a reference when splitting the animation into chunks.
* The previously mentioned time could have been greatly extended by enabling the umbrella and giving the player instructions to open it and keeping it that way during the entire sequence. I chose not to go with this approach because I wanted the entire thing to be fully automatic and minimize the risk of the player doing something unexpected that would break the sequence and/or cause audio desynchronization (e.g. closing/re-opening the umbrella
at any point).
* The PNG files generated by ffmpeg and ImageMagick were not using the best possible level of compression, and I was able to further reduce the file size of each PNG strip simply by opening them in GIMP and saving them again with a compression level of 9 (max). This allowed me to cut down the total size of the animation from ~4.2MB to ~3.6MB.
* The last problem I had to deal with in order to get the video to play smoothly was the flickering during screen transitions, which caused the screen to go completely black for a fraction of a second (objects are not rendered in the first render pass in vanilla KS -- only the gradient and the tiles are visible at that point). The workaround for this was to extract the first frame of animation for each of the 16 chunks and convert them to gradients, then set the background in each screen to the appropriate gradient.
* When I first finished implementing the entire thing in KS, I noticed (way too late) that I had screwed up when cropping blank frames at the beginning from the original video, and that the first 60 frames of animation were missing
Since I didn't want to export and optimize the whole sequence again, I resorted to patching in the missing frames in an extra screen and manually adding a few delay cycles at the start.