Programming help wanted (for hire)

Noisy images are always a bit of a problem, but you use the right tool for the job. I pretty much handle these very cases in the animation data. For example, it's easy to describe a whole load of noisy pixel information that starts and ends on the same frame (without having to specify each and every like z coordinate). For general cases though, the algorithm actually works great. The limited color palette means there ought to be areas of like-color between frames, and even when their aren't, each frame compresses down into the space of several thousand bytes, rather than hundreds of thousands. I should note that part of the issue of this program was finding a way to quickly compress and decompress data. It's relatively quick to compress (by the time the user lifts the pen, the entire frame (and all of the undo information) is already stored in memory. They can move to the next or previous frame without hesitation), but more importantly, it's quick to decompress. The stored data is mostly just a list of graphics drawing instructions, and we can draw many many many quads per frame. I get a lot of heat from programmers who hear about my whole rectangle compression thing. I think there's only one other method that can rival this (and in all honesty, I should've explored it further because it is probably a better approach than this), but I believe this is one of the best ways to go about this in SB, with all the limiting overhead.

N3DS doing ~40 fps

https://youtu.be/DgHiNvrWDp8 About the only video I've got handy at the moment. This one actually uses GSAVE2 instead of the better GS4. http://smilebasicsource.com/page?pid=1535

That's just a bunch of rectangles and triangles. I'd be interested in seeing how it fares against actual Flipnote frames.

Not very well to be honest, but what can you do? My only option for rapidly drawing noisy imagery (paints, especially when mixed, can start looking pretty noisy) is to keep it in a GLOADable form, or at least very near that form. iirc, successive GLOADs have a max frame rate of around 30 fps (on N3DS, don't know the damage on O3DS), so, too many of those per frame and there'll be frame drops anyway. Your method sounds a lot like the Flipnote .ppm structure, which is mighty compressed. Like, 999 frames pack into little more than 4000 kb iirc. But Flipnote has the benefit of access to the system hardware--less overhead. Decompressing a frame under that structure in SB could take literally whole seconds. Anyway, the trade-off for less memory usage is the redraw rate, and the trade-off for a faster redraw rate is more memory usage. I've explored many options and I think this option is best. --- So, the animation editor of my app relies on 2d frame compression, because, well, I guess that's how the undo system needs it to be. Playing back animations in the editor will likely yield frame drops if you use a lot of paints or noisiness. My intent was to give the user the option to export a more streamlined version of their animation as a "final product" sort of deal. (That is, a small, shareable file playable in the SB app.) That's where GS4 came in. It's purpose was to make the animation playback consistent at its framerate and keep the file small--but, now that I think of it, there's no real reason to keep the file small, especially if it's the "finished product." What I can do instead is some kind of weighted calculation during compression, tracking the tradeoffs it takes between more memory usage and more rapid redraw rate in an attempt to meet that goal of consistent frame rate (while respecting the maximum file size of like ~8 mb of course). It can allow the file to bloat up approaching the max file size, trading memory usage for redraw. But, the animation playback in the editor can't have that luxury. I should also note that GS4 is also intended for the PC export. It is much much faster than LZing each frame, mostly because it could skip areas of the screen it previously compressed and it worked on 16 frames at a time. Each coordinate (x,y,z) only occupies 22 bits, making each prism cost 44 bits. If the volume of the prism exceeded at least 44 voxels, which was almost always the case when one drew with solid pen, then it was saving space. If it couldn't compress a prism along the degrees of freedom for less than 44 voxels, then it would attempt 2d compression (two (x,y)'s) on the top frame, where the coordinate cost is 36 bits. If it falls short there, then it would flag it for noise.

Well, I know that you're searching people for hire to a flipnote program, but it's too much for SB3 to make program make drawings with complex pixels. I still haven't made the code of my flipnote perspective for SB3 but its a bit friendly than the normal flipnote. Here is an example of what I'm trying to explain: I think its not hard as I think, because I have in the hand the grp editors, and in the other hand, my inspiration and ability to make similar codes without copying them directly from games. And, no, I dont want money because of helping someone to make a program. Its fine for free ;)

I haven't tested it yet, but just exploring the code from the website, looks like it encodes 16 bits into 4 horizontal pixels? If correct (which it probably isn't, because I haven't explored the code so thoroughly), that puts it at 2 bpp which, if--

... and I think they found that you could use 5-bit grayscale reliably. So, each pixel would store 5 bits instead of 1. So, about 60KB per image. Not bad.

--holds true, then uh perhaps the creator of PM relied more on their wonderful LZSS compression in the screenshot method, rather than exploring avenues for stuffing in more bits per pixel. Maybe the screenshot method could be made better?

PetitModem encodes 5 bit per 2 pixel(2.5bit/pixel).So it transfer (400x240+320x240)*2.5=54kByte per 1 screenshot(2 images). because JPEG compression uses YCbCr space and has color cross talk and irreversibility, I use special set of colors and pair of them. 4 kind of gray, 2 of blue, 2 of green, 2 of red, 2 of cyan are used as a pixel color, which are farthest in each other in YCbCr Space.(to minimize compression noise) and they are drawn on the pixel in such way that (2n,y) and (2n+1,y) pixel has same CbCr value. (to minimize color cross talk) So, 4x4+2x2+2x2+2x2+2x2=32 case (=5bit) can be recorded at each two pixels. I think it is impossible to encode 5bit per pixel (which means they give up to use CbCr data and use ONLY and ALL OF Y data) Because 3DS JPEG compression is irreversible even if the image is totally monochrome. In my experiment, in monochrome image, one can transfer 5 case per pixel, which means 2.32bit/pixel. by the way, in few years ago, I made movie player/decoder for SB3, which uses RLE of the difference of each frame. it is almost same to what Chatter says. Flipnote is something like "a set of image". so simple compression mechanism such as "get difference of previous frame" could be the best.