Old versions:
Decided to write an encoder for 128x128, 2 color, 1 pixel scrolling, and one rectangle per frame
After a bit of tweaking, it outputted this. Some parts of the video are entirely unrecognizable and just look like jittery boxes sure, but it's interesting.
Changelog:
v1.0.2:
Ignored the data for left and right scrolling, it's invalid.
v1.0.3:
Regenerated a new rectangles version with valid scrolling data + the extra tweaks.
8% better
v1.1.0:
Added circles
Fixed left/right pixel scrolling: the encoder was outputting garbage due to a typo.
v1.2.0:
Rewrote encoder in C
Added faster scrolling
Left space for music and sfx
A bit indecipherable, but you put in an amazing amount of content in there. Could you describe the rendering and encoding method in more detail?
A bit indecipherable and noticeably slow. Though most people probably won't try to sing along!
Sure: it has 4 bytes per frame which 6474 frames ends up at 25896 bytes in total
I can shove about 0x4300 or 17152 bytes through out the gfx, map, sounds, music, etc parts of the cart.
The remaining 8744 bytes get encoded as a long string that happens to pretty much take up all the compressed space of the cartridge.
in general, the 4 bytes are: x1, y1, x2, y2 for the rectangle
The very highest bit of x1 controls whether the color is white or black
The highest bit of y1 controls whether the screen scrolls up/left
The highest bit of x2 controls whether the screen scrolls down/right
And the highest bit of y2 controls whether the scrolling direction is up/down or left/right
if y2%128 happens to be 0 however, then the following happens:
in general the 4 bytes become: x, y, radius, 0 for a circle
There are no circles in this version though, still working on tweaking the encoder.
EDIT: And yeah it's rather indecipherable, even if I were to brute force every combination of data for the most amount of progress towards the correct image, it would still look bad since there's a limited amount of data it can put out per frame.
Debating if circles are worth it or if lines might be a better choice for a secondary shape.
Made a new version that uses circles, is calculated to be 17% better! Also fixed a silly bug in the encoder. accidentally had a typo that would corrupt the cache every frame, the left and right pixel scrolling data in the old version is invalid and should be ignored.
Good job! This adds a lot more detail to the scene and goes a looong way in making the characters visually distinguishable in many cases.
I'd never seen the video before, and I could still mostly tell what was going on. Then I went on YouTube and watched the full thing and I was honestly surprised at how accurate it was. Not bad! Reminds me of the cutscenes in Out Of This World.
Yeah, the main problem here is that the video is so lengthy that a super-detailed encoding is impossible. What it does instead is, basically, just place only a single rectangle or circle per frame, in whatever way an algorithm determines results in the closest overall resulting picture to the original. I think it does this by brute force, since gamax92 is baking these carts over an entire night whenever there's significant improvements.
Considering how little space the Pico-8 allows you to work with, these results are fairly staggering, and could only be improved by potentially rendering more shapes per frame, changing the source video to have less momentum, or using a non-png .p8 file to bypass the compressed code limit (and run into the Lua memory limit instead)
Been a while. Back in July 2018 I rewrote my bad apple encoder in C, made it more accurate, and added in one more effect code: repeat last effect twice. This allows the encoder to perform double scrolling and helped decrease the error score. I also made the embedded data more efficient and left room for sound data, there's 767 bytes free in this cartridge. Didn't add any music in there yet though.
And then stuff happened in life and I forgot to post this so, here it is almost a year and a half later
EDIT: Just found an optimization oversight in the cartridge encoder so, there's actually 861 bytes free
Probably the best Bad Apple around, @gamax92. You get my star.
Here now we can consider this. We have RAM space from 0x8000-0xFFFF and can poke bytes in that area. Perhaps increase the compression, increase the video quality and use that extended memory as the foundry to release it all.
[Please log in to post a comment]
