A little background first. Recently, I've picked up the idea of creating an animation program on SB, like a throwback to Flipnote on the DSi or something. Nothing serious because, of course, this is SB. But I've always like the idea of drawing on the 3DS, I think it's a great platform for such things.
Anyway, I've made tons of progress on this idea and have a few functional designs. Originally, I thought it couldn't be done for essentially two main reasons: processing time and available memory.
See, an animation program needs to store frames--images. Older programs that I've seen on PTC accomplished this by simply storing all the points of where the stylus met the screen (and some extra data like pen color, pen size, etc.) in an array. To redraw any particular frame, the program would simply loop through the array and re-enact every step it took you to draw that particular frame, only a lot faster. Though, often not fast enough. If you spend any great length on drawing a frame, then the program takes just that much more time to draw your frame, and a frame of relatively little complexity could take a substantial amount of time to draw. Sometimes entire seconds, no good for displaying animation at 12 fps. This is an example of the processing problem.
I've also seen here on SB3 another method: GSAVE. GSAVE is a function that simply takes all of the data on the graphics screen and stores it in a 1D array. It makes no effort to compress the data whatsoever. If you make an animation program that stores frames of animation by simply GSAVEing them, you'll run out of memory after about a dozen frames. No good. That's the available memory problem.
My current working method is... great, yet crude, I think. Actually, the method is twofold, one for compressing the frame and one for decompressing the frame. You want both to fit the processing and memory bills, but necessity requires that the decompression be speedy and consistent. If the program requires a moment to compress the frame you've just edited, then, well, so be it. You may stare at my cool spinning icon.
My current working method (I call it rectilinear compression, but considering its simplicity it probably has another name) can take a 320x240 frame comprised of two RGB colors and compress it down to somewhere between a few and a dozen thousand bytes, depending on complexity. For comparison, a GSAVEd frame costs about 300k bytes a pop. I'll probably link a key to a demo of the code behind it (it's really not that impressive), but, put simply, it finds simple shapes (straight lines and solid rectangles) in a frame and re-represents those shapes with start- and end-points. (Instead of storing every pixel, it finds areas of the drawing that are either solid or straight lines, and assumes all the pixels in between by computing the shape's vertices.) What my program gets back from the compression is a 1D array filled with points that perfectly describe the input frame, and it draws well too. Average frames can be displayed at 50-59 fps, though, frames with great complexity can knock that down to 30 fps or lower. Oh, and by "average," I mean me scribbling lines all over.
I'm an amateur at this, and I have little in the way mathematical creativity no matter what Numberphile leads me to believe of my abilities. Y'all got any clever ideas for this sort of stuff? Suggestions? Any clever SB tricks? A key to a fully-fledged, hand-drawn animation application so i can go to bed...?
TL;DR: Animation app requires stores frames. Frames compressing requires processing and memory. How program make compress frames fast and little memory used?
