Bad Apple demo for SNES

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
tokumaru
Posts: 11469
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Bad Apple demo for SNES

Post by tokumaru » Sat May 25, 2019 3:31 pm

supercat wrote:Have you tried porting that to the NES? I'd say it looks pretty good.
Nope, I just wrote a script in PHP to encode the tiles (don't know if I still have it) and made a GIF of the result.

I though it looked cool too... the fluidity really compensated for the incorrect pixels, IMO. Making a demo should be trivial, all the work would be in selecting a compression scheme that worked well on the name table data. Just a little bit of forced blanking should be enough to guarantee a frame rate of 30.

supercat
Posts: 161
Joined: Thu Apr 18, 2019 9:13 am

Re: Bad Apple demo for SNES

Post by supercat » Sun May 26, 2019 10:02 am

tokumaru wrote:
supercat wrote:Have you tried porting that to the NES? I'd say it looks pretty good.
Nope, I just wrote a script in PHP to encode the tiles (don't know if I still have it) and made a GIF of the result.

I though it looked cool too... the fluidity really compensated for the incorrect pixels, IMO. Making a demo should be trivial, all the work would be in selecting a compression scheme that worked well on the name table data. Just a little bit of forced blanking should be enough to guarantee a frame rate of 30.
What do you think of the idea of using cartridge WRAM to hold a sequence of "lda #xx / sta $200x" instructions? If you're using 32x24 normal-height tiles (as opposed to using half-height tiles to enable arbitrary half-resolution pixel patterns), a worst-case update would be 4620 cycles, which is only about 40 scan lines, and significant compression could be achieved by simply evaluating the differences between frames, identifying what combination of vertical and horizontal updates could best achieve them, and arranging to have the store sequence contain mostly stores to $2007, but a few pairs of stores to $2006 and possibly one store to $2000 (to switch from horizontal to vertical updates). If one imposed a limit of 303 PPU writes per 60Hz frame, it may be possible to get by without cartridge WRAM or extended vblank. I don't know how many frames would need more than 303 tiles to change at once, but I'd guess many of those could be handled if one set the four palettes to black/white, black/black, white/white, and white/black and then used palette updates to switch set the attributes of groups of 16 tiles at once.

Bad Apple's popularity may have passed, but I think the existing demo falls far short of what the NES should be able to achieve.

User avatar
tokumaru
Posts: 11469
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Bad Apple demo for SNES

Post by tokumaru » Sun May 26, 2019 11:01 am

supercat wrote:What do you think of the idea of using cartridge WRAM to hold a sequence of "lda #xx / sta $200x" instructions?
I think it's useful in other cases, but not really needed here. Since the picture is only 24 tiles high, as opposed to the full 30, there are 48 scanlines with no picture that we can blank and use for VRAM updates, plus the regular 20 of vblank. Updating all 32x24 tiles plus the 64 attribute bytes at the "slow" rate of 8 cycles per byte would take less than 60 scanlines, so you could even do 60fps video if you wanted. VRAM transfers are not the bottleneck here.

The real bottleneck IMO is PRG-ROM space, since common Nintendo mappers only go as high as 512KB. You'd need a fairly advanced compression scheme to make efficient use of the available space, meaning that the decompression process could end up being too heavy for the CPU. How many frames does the entire animation have? We need to divide the available ROM space by that in order to find out the average bitrate that the compression scheme must achieve.

User avatar
tokumaru
Posts: 11469
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Bad Apple demo for SNES

Post by tokumaru » Sun May 26, 2019 11:25 am

It looks like the video is 3 minutes and 39 seconds long, or 219 seconds. Times 30 frames per second, that's a total of 6570 frames. If the total PRG-ROM size is 512KB, the average data rate would have to be 524288 / 6570 = 79.8 bytes per frame. Yeah, getting 832 bytes down to 80 sounds like a real challenge. We'd need really good temporal compression, in addition to spatial compression. And there's also the program and the music stealing some of that space. Maybe CHR-ROM could be used for some extra storage?

psycopathicteen
Posts: 2904
Joined: Wed May 19, 2010 6:12 pm

Re: Bad Apple demo for SNES

Post by psycopathicteen » Thu Oct 10, 2019 2:26 pm

https://www.filehosting.org/file/detail ... 0Apple.zip

Works perfectly in BSNES. I got it working in SNES9x again, you just have to hit reset in SNES9x to get it to work correctly for some reason. I still can't figure out why it doesn't work in Higan.

EDIT: Wait, it works in later versions of Higan.

Here's the best version:
http://www.mediafire.com/file/nkqvxq2tm ... e.zip/file

93143
Posts: 1109
Joined: Fri Jul 04, 2014 9:31 pm

Re: Bad Apple demo for SNES

Post by 93143 » Fri Oct 11, 2019 10:44 pm

What's new? It's been a while since I saw one of these... I believe there was some issue with getting the sound to work on real hardware; has that been solved?

psycopathicteen
Posts: 2904
Joined: Wed May 19, 2010 6:12 pm

Re: Bad Apple demo for SNES

Post by psycopathicteen » Sat Oct 12, 2019 9:39 am

It works on every emulator now, so chances are it works on real hardware too.

tepples
Posts: 21755
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Bad Apple demo for SNES

Post by tepples » Sat Oct 12, 2019 3:37 pm

Works on my PowerPak
Attachments
Bad_Apple_works.jpg

93143
Posts: 1109
Joined: Fri Jul 04, 2014 9:31 pm

Re: Bad Apple demo for SNES

Post by 93143 » Tue Oct 15, 2019 1:40 pm

I assume this photo of one of the frames being displayed properly is intended to imply that the audio works the whole way through too...

...

Performance looks good, at least in Snes9X (which has hotkey frame advance). Several lag frames with Flandre, but I didn't notice any in the other traditional trouble spots (the tree and the musical poltergeists).

I believe you had a scheme in mind where the tilemap decompression happened during VBlank, thus opening the road to possible use of HDMA during the frame. (Or does the tile decompressor use DMA too?) Have you had a chance to look at that?

tepples
Posts: 21755
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Bad Apple demo for SNES

Post by tepples » Tue Oct 15, 2019 1:45 pm

Yes, audio plays on my 1/1/1. But I'm not intimately familiar enough with the original to tell with certainty whether this version keeps perfect sync.

93143
Posts: 1109
Joined: Fri Jul 04, 2014 9:31 pm

Re: Bad Apple demo for SNES

Post by 93143 » Tue Oct 15, 2019 2:37 pm

Yeah, it's not going to keep perfect sync. We've had this issue before.

1) that TV of yours looks like it's probably got a bit of internal lag,
2) the nominal video and audio clocks aren't exactly 60 and 32000 Hz,
3) on real hardware, the video/audio sync isn't reliable anyway due to the APU's use of an independent ceramic oscillator,
4) the source video doesn't seem to have had perfect sync in the first place.

With emulators it's even worse.

Anyway, the proof of principle is what's important. From that perspective, as long as the audio plays cleanly on real hardware, we're good. Audio glitches are much more noticeable than lag frames, so it's easier to be confident in a clean playback. Once it's running with zero lag frames and 24 kHz stereo, we can badger him about synchronization...

tepples
Posts: 21755
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Bad Apple demo for SNES

Post by tepples » Tue Oct 15, 2019 3:28 pm

Much of the song (prior to the gear change at the end) appears to be played twice. Can that be exploited to increase the sample rate or add a reduced-frequency side (L-R) channel for mid-side stereo?

93143
Posts: 1109
Joined: Fri Jul 04, 2014 9:31 pm

Re: Bad Apple demo for SNES

Post by 93143 » Tue Oct 15, 2019 6:13 pm

Maybe. If chunks of it are effectively identical to each other, you could reuse the data. It could be complicated to line up the BRR blocks accurately enough to make it work seamlessly... and you'd have to make sure they were really identical, lest you get caught cheating by someone who knows the song better...

I don't know how much free ROM there is in the current version; I had the impression it was fairly tight. But it's only 64 Mbits, and a 95 Mbit ROM would still work on all the flash carts that can handle 64. Assuming the video decoder can avoid using DMA during active display, and that stable high-bandwidth HDMA streaming can be made to work, there's enough room in a 95 Mbit map for 24 kHz stereo, or 32/16 kHz mid-side, with no weird tricks. Using your proposed scheme, if enough of the music data turns out to be reusable, 32 kHz stereo might even work.

What bugs me about this idea is that it seems to have the same issue my trick with highpassed samples does, which is that it's content-specific and requires manual work; thus it doesn't really qualify as a codec...

tepples
Posts: 21755
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Bad Apple demo for SNES

Post by tepples » Tue Oct 15, 2019 6:33 pm

The mp3 PlusV codec (see discussion) attempted to represent everything above 8 kHz as noise shaped by a spectrum envelope. This was a simplified counterpart to mp3PRO, which used spectral band replication and some per-frame metadata to copy low frequencies to high. Perhaps some techniques from PlusV could help turn "highpassed samples" into an actual codec.

93143
Posts: 1109
Joined: Fri Jul 04, 2014 9:31 pm

Re: Bad Apple demo for SNES

Post by 93143 » Tue Oct 15, 2019 7:47 pm

So... an automatically generated timestamped list of 8-tap FIR filters (or indices into a table thereof) and volumes/envelopes to use on a noise channel, using an EDL of 0?

In any case, you'd get monaural high frequencies, so if you've got extra bandwidth you might be better off with 32/16 mid-side. On the other hand, this might fit in 64 Mbits and might not require radical changes to the audio engine. And on the other other hand, maybe you could use this together with 32/16 mid-side to generate pseudo-32/32 mid-side that fits in 95 Mbits...

Can a filter that short provide the necessary steepness and complexity to make this technique sound decent? I don't like the idea of automatically-generated prefiltered noise loops; that could sound pretty terrible and/or require an inordinate amount of intelligence from the codec, especially given the strict bandwidth and audio RAM limits. But perhaps one highpassed noise loop could be justified more easily; that way the onboard filter wouldn't need the steepness to stay out of the sampled music's range without leaving a big hole in the spectrum. (A modest highpass component might still be a good idea; BRR tends to add noise back into the low end regardless of how steep the prefilter is.)

More importantly, it seems to be impossible to guarantee glitch-free filter updates for dynamic spectrum shaping. The fastest method I can think of would take two samples at 32 kHz between the first and last filter coefficient writes, which means a couple of sample points would go through a partially updated filter every time. Since it's noise, maybe it wouldn't sound too bad... and some of Ocean's soundtracks seem to have used a similar technique; I don't know if they used the whole filter, but Dean Evans said some of their fancy techniques could produce pops at times...

...

Perhaps I've dismissed the idea of automated generation of multiple shaped-noise samples a bit too quickly. You could have a rolling cache of them in ARAM, reloading older ones as needed if they've dropped off the back and been overwritten. With HDMA streaming, the hit to video decoding compute time could be minimal... as long as care is taken to keep the total bandwidth low, since of course if you go too nuts you could end up with a string of unique samples all crossfading into each other, which would take more bandwidth (and data) just for fake sizzle than you'd need for an entire 32 kHz track...

If the FIR filter method reliably sounds okay, it might be more elegant... Either of these methods would also probably ease timing requirements vs. my highpassed samples idea, which needs very precise trigger points (all these methods likely need APU-side timing because the potential drift rate vs. the main clock is just too high, but it helps if the effect doesn't sound stupid because it was supposed to trigger in the middle of a 32-line HDMA burst and had to wait)...

Post Reply