In order to reduce complexity and avoid a bit of scope creep, I've opted to remove multiple compression methods. I'm glad I tried it, but now I know for sure zx0 is the way to go. Anyways, I got a bit antsy and started GIF support already.
There's three main concerns to address:
Storage, frame rate, and memory constraints.
Storage:
Storage constraints are a huge concern for animations since worst-case, the calculator would only be able to store about 40 frames of full resolution. Of course, zx0 automatically saves ~40% on each frame, but that still only increases the maximum number of frames to 66. For now, I've halved the resolution to 160x120 which instantly quadruples how many frames we can store to 264. This is only temporary so I need to save storage space some other way.
For most GIFs, there's a lot of data that doesn't change each frame such as static backgrounds. Instead of storing all the data to re-create each frame all on its own, I only store the parts of the image that are different from the previous frame. This allows me to just overlay the pixels that actually changed onto the previous frame. This makes compression much more efficient. The magenta color represents the colors that didn't change from the previous frame.
(First frame | Second frame)
While this significantly helps for clean GIFs with static backgrounds, tons of GIFs are low-quality noisy conversions of videos. Noise really hurts compression. We can mitigate this by binning colors so similar colors become the same color. I'm currently reducing the bits assigned to RGB to 3-3-2. You can see there's a massive difference when comparing these two frames. More magenta generally means better compression.
(Both are the same frame from the same GIF. The first has full color quality. The second has the colors binned.)
After all this, how many frames can I store? I converted about 20 seconds of Never Gonna Give you Up which is a decent stress-test since it has lots of motion and significant scene changes. It outputted 300 frames totaling 1.2MB. That means the calculator can store over 600 frames!
Frame rate:
My target is 10fps with a stretch goal of 20fps. HDPIC was originally designed for displaying static pictures so render time wasn't that important. This meant I was finding each appvar at render-time. This actually isn't
too slow but I'm trying to cut processing time wherever possible. Now the program finds the pointer to each appvar during initial startup. That way when it's time to call a specific frame, the calculator knows exactly where to look for the data.
This works really well and I can get ~40fps when displaying the GIF at 160x120. If I try to make it full screen using ScaleSprite_NoClip() this destroys the frame rate down to just ~10fps. I don't think this is actually a huge deal. I plan to switch to native resolution GIFs anyways which means no scaling will be necessary. I fully expect I'll still hit above my 10fps target.
Of course, I'm storing the proper frame times so the calculator only displays a new frame when necessary.
(You can see the slowdown when entering full screen)
Memory Management:
HDPIC was originally written to only use dynamic memory allocation since a) that's all I knew at the time and b) since I was using scaling, I didn't know how much memory to allocate at program startup. This started causing memory fragmentation and instability as I started reserving more and more memory.
After a gentle berating from Mateo, I've started learning how to use static memory allocation. There's some parts that are easy to allocate statically. For example all sub-images are always 80x80 and all GIF frames are currently 160x120. The memory quickly starts piling up though.
8bpp images:
- 6,400 bytes for the initial storage where the appvar data is stored to.
- 6,400 bytes if I need to bit-unpack 1,2, & 4bpp images.
- Up to 57,600 for a subimage scaled up to 240x240.
16bpp images (everything is twice as big as 8bpp):
- 12,800 bytes for the initial storage where the appvar data is stored to.
- Up to 20,000 bytes for a subimage scaled up to 100x100 (this is artificially limited).
GIFs:
- 19,200 bytes for a 160x120 frame.
I only foresee memory usage increasing as I switch to 320x240 GIF frames and add other features in the future. I can't statically allocate all this memory at the same time. However, I realized I don't need all the memory allocated at the same time. A 16bpp image will
never be displayed at the same time as a 8bpp image or GIF. Likewise an 8bpp image will never be displayed at the same time as a GIF or 16bpp image.
This means I've been trying out using a C++ Union. This basically allows me to use the same memory space for different variables. This has worked pretty well so far! The memory is always overwritten with picture data before it's read so there's never an issue of reading leftover memory from a different picture mode.
Conclusion:
What does all this look like in practice? I'm pretty happy with the results so far! CEmu won't transfer all the appvars for some reason so there's way more artifacting than you see on a real calc.
Real-world example (a single frame got corrupted):
https://i.imgur.com/mhWmMzs.mp4
I guess I'm obligated to run Bad Apple on this at some point...
Voblit wrote:
Yo how do you get the cool banners at the bottom? also HOW ON EARTH IS IT SUCH HIGH QUALITY?!?!?!?!!?!??!?! Respect!
You can add banners in your Cemetech profile settings. The quality is much higher since I'm storing unique color data at full resolution rather than TI's approach which upscales from a very low resolution. 
