Nice to see some competition.   By the way, I'm currently at 966,656 bytes including executable code and wasted space in the app pages.

To extract the frames, I losslessly reencoded the video in handbrake, resizing it to 96x72. (I'm sure I could have done the cropping in that step as well, but the settings are confusing.) Then, I ran ffmpeg on the resulting video, using (if I remember correctly) -o badapple%05d.png to output each frame to a numbered .png file. From there, my python encoding script crops, converts to monochrome, encodes, and places into page .bin files each frame.

Second attempt. This one took a much longer amount of time to accomplish, as there were many problems both with the Java side of things and with SPASM, not to mention the woes of trying to get my 4 channel audio interrupt to work with the renderer and keep the decompressor running in the background at all times.

I still use pucrunch, but this time around, I decompress to ~16KB blocks and have the renderer scan across it.

After some manual tinkering with the data block locations, I've got the app down to 835,584 bytes total. There's still a disgusting amount of space being wasted between pages and I'm sure I could reduce the size by another 16-64KB if I coded the Java side of things to actually sort and try to fill the gaps.

Anyway.

Even tho there is no (real) music, the 4 channel audio interrupt *is* running in this screenshot at a very low frequency hum (as is the setting if not initialized). The video itself is much smoother on-calc, despite the fact that there is frame-skipping logic if the video can't render at ~30FPS.

-------
EDIT: Music *can* play. I just don't have a track to play with the thing yet.

Also, there's still an unidentified encoding problem. I don't know if it's with pucrunch or if it's the Java code unreliably reading in the .png files. Or if it's a problem with the frameskip logic.

EDIT3: Maybe I should try apack next, just for the fun of it?

Changes:

* Size reduction (now 737,280 bytes on-calc)
* Video playback perfect
* Aspect ratio preserved. Video cropped on left and right to fit.

What happened:

Implemented a page filling algorithm that actually tries to fill in the gaps between pages with data by sorting through the chunks to see what will still fit, starting from the largest available piece working its way down the list until none of the available blocks will fit any more. Saved 48-64KB.

Changed compression/decompression scheme from puCrunch to APACK. This fixed the video playback corruption issue, which doesn't inspire much confidence in what I had before. APACK also seems to perform better than puCrunch in this application. Saved another ~48-64KB.

In an attempt to fix the playback problem, I performed much of the video/image processing in FFMPEG instead of doing the ridiculously slow batch file conversions in Irfanview. Although I spent more time learning how to actually use FFMPEG than it did if I had actually went through with the batch conversion, I learned how to use it better, which makes me happier. Unfortunately, the destination folder went up dramatically, as I was unable to figure out how to change color depth of the output .png files. But, I was able to perform resizing (while preserving the aspect ratio), cropping the video, and (as was done before) splitting the file into its individual frames as PNG's.

Also, the Java script had to be changed to handle PNG files that had a color depth of more than 1bpp. If it had a color depth of 1bpp and you knew the image was 96x64, you could create an ImageData object (from the SWT library), then do something like "myPictureObject.data" to get a data stream that's binary-compatible with the calc. Just put that data into a source file and LDIR it to a screen buffer. But... since I couldn't do that anymore, I had to change it so that it actually scans through the file and creates the bitmap. Ah well.

When I changed from puCrunch to APACK, the application's performance characteristics didn't change all that much. If anything, APACK is a slight bit faster than puCrunch, but I'll have to test using an actual stopwatch later on instead of counting it out.

The audio interrupt is running at 24KHz. The app has 23-29% free CPU clocks left.

I can no longer continue this project until I have finished (or at least, completed basic functionality) my on-calc music tracker project. So unless there are other suggestions (I've already tried KermM's mt3 converter, with no luck), I'm putting this on hold for a while.

Or... if you happen to have the music for Bad Apple playable via MobileTunes3, this will plug right into the app, albeit at the wrong octave (due to the app running at 24Khz vs the required ~62KHz)

EDIT: Whoops. Forgot to upload the video. I'll do that now.

Very nice! I can't wait to hear a version with the sound ON (Video).

It is indeed really good. You could do a video to show how well this runs on a real calculator and have it uploaded to Youtube / Dailymotion / whatever video site you want to use. The gif is nice, but nothing shows the completion of the project like showing it running on actual hardware.

I think it would be best to wait until a download link is available, else people there will think it's fake.

Someone can make a version for TI-84+ not SE ? as if the version is not long ? please

Iambian, what are you using to calculate CPU usage?