D3thAdd3r wrote:AE was a quick recording hack but it was space efficient and I think demos were on the order of ~100bytes(though stored on SD). Basically 1 byte of pad state and 1 byte of frames to hold that pad state(the "RLE" part of it), if you really felt like efficiency, you could get away with 5 bits since there is only 1 action button. I implemented something that spit it to eeprom where I manually ripped it by discarding the 2 byte ID in between every 30 bytes of demo data. Pretty fast to implement, though actually recording and assembling the data together took a bit, was tedious, but at the end worth it.
Cool. I would really want to show off the P1 VS P2 mode, but getting an input capture of that will be tricky, and might have to involve multiple keyboards, because if too many buttons are being held down at once then it locks out any new keypresses, making it impossible to play in the emulator. Or I could try rigging something up with my logic analyzer and the real hardware to capture both players' inputs from the real system.
And it seems that the input capture feature completely ignores player 2.
D3thAdd3r wrote:On the Uzebox logo, you might save a bunch of flash if you implement a custom one with ram tiles reusing some of your bug sprites. You could probably replicate the existing one as well with 4bpp graphics and some small code to save a bit. The pain with pallet stuff right now is there isn't good tool support so you might have to mess manually with the graphics using text replacement to get the colors you want.
Hmm, it looks like I can fit it as is, especially if I disable Channel 5, which should even save me some cycles! The only problem is the intro is hardcoded to use WAVE #8, but I've pared them down to just the 2 WAVES that I use. I have enough space to add the one it wants, but it certainly won't be WAVE #8.
Edit: I just checked, it saves hundreds of cycles, sometimes on the order of 600 cycles per frame, which is pretty insane!