Bad Apple!! in Sonic 1 (32X) Spoiler: Screenshots Yay! Another Bad Apple!! demo thingy! I originally made this last year as an exercise, and oh boy did it turn out to be an exercise in frustration. Simply put, this is the Bad Apple!! shadow art video, displayed on top of Sonic 1 by using the 32X. Because why the hell not? I can do whatever the fuck I wanna do. Technical Nonsense This is the entire video, at 30 FPS (or 25 FPS in PAL), with its original audio played back via the PWM sound chip. It's displayed with only 2 colors mainly for optimization, meaning cramming 8 images into 1 and then using palette cycling to highlight the pixels of a specific image, by assigning an image per bit in each pixel (because 32X palette mode uses 8 bits per pixel). Helps with storing less data in the ROM, and also makes streaming a lot easier, as I only have to retrieve a new image every 32 frames (not 16, because each video frame is displayed for 2 frames, so yay, bonus time). The video and audio are streamed out into the 32X's memory from cartridge, which uses the Sega (SSF2) mapper to enable bankswitching and be able to store all the data. Compatibility In terms of emulation, I only know that it works on PicoDrive and ares, because they allow both the 32X and Sega mapper to be used simultaneously. The version of PicoDrive on RetroArch can run this just fine, but not the one on BizHawk, because it's out of date (in fact, don't use BizHawk for this, because the audio will be corrupted and loud, and the video will only play for a bit and then repeat). Kega Fusion will not run this, because it doesn't do the 32X and Sega mapper simultaneously, and it has a 6 MiB limit for the mapper anyways (compared to the actual 32 MiB limit on hardware). In terms of hardware playback, apparently, according to some people, it does work on hardware! I'm actually really surprised, because I'm admittedly a 32X noob, and the 32X is honestly a massive pain to deal with. Wasn't this already released in the mini projects thread? ...uhhhh... shhh... This one is slightly different, though, as I did fix the background color so that it converts the Genesis background color value to a 32X color value, and then replaces the white with that. So there's that...? Credits Me - Programming ZUN - Composed the original version of Bad Apple!! Alstroemeria Records ft. nomico - Making the famous cover of Bad Apple!! Anira - Creator of the original shadow art video Sega - Made the 32X, the reason for my misery Links Download Source Code
I like how Bad Apple lasts exactly as long as the three acts of GHZ in your first video, even if you lost quite a bit of time at the last breakable wall. This is great, by the way.
Dude... do you realize what you've done? You've just created the first step for a meme ecosystem much like the GBA Video tools!
I mean, if you like 1BPP videos... As I mentioned in my post, it fits 8 1BPP frames into 1 image and uses palette cycling to display a frame. The video runs at 30 FPS (25 FPS in PAL), so a single combined image is displayed for 16 frames, with each individual frame in the image displayed for 2. The code uses that time to upload the next image into the frame buffer, and swaps when the time comes to display it. This method also allows me to significantly save up on ROM space, and even more so with the fact that I'm using the run-length encoding display mode so that I can store compressed images. With it running off a cartridge, it is quite quick to read and store the image data into the frame buffer, unlike a Mega CD disc image, where I would need to stream from the disc, and adhere to the drive speed. I could definitely do 60 FPS (50 FPS in PAL) videos, since 8 frames per image is still enough time to upload the next image into the frame buffer (though, that would mean more images to store in the ROM). The issue really just lies with cartridge space, because the mapper only allows up to 32 MiB. Increasing the bits per pixel would introduce some challenges with ROM space (i.e. doing 2BPP videos would only allow 4 frames per image, so you'd need to store more images on the ROM). The key is to figure out the trade-off between image quality, frame rate, video length, and ROM space. Oh yeah, and there's also the fact that you'd still need to store the audio track in the ROM, too, so you gotta account for that, too.
