Bad Apple demo for SNES

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
nocash
Posts: 1405
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Bad Apple demo for SNES

Post by nocash »

Is there any synchronization (using APU timers, or ENDX flags)? I can't see any such thing, the APU code seems to be receiving any incoming data, and "blindly" writing it to sound RAM.

Synchronization is required because the APU uses a different osciallator than main cpu & video, and the APU clock should be rather inaccurate since it's only having a ceramic oscillator, which may be faster/slower on different consoles (not too mention factors like different temperatures).

One approach would be using the APU clock as master: waiting (or frameskipping) at main cpu side whenever the APU has complete one audio frame.

And maybe better would using the main CPU clock as master: in that case you would need to brew up something that does dynamically increase/decrease the BRR sample rate as needed (ie. if the sound engine completed the sound-frame faster or slower as expected by the main cpu, then adjust the BRR rate accordingly). This approach might be a little more complicated, the advantage would be that the audio clock is effectively derived from the (more accurate) main cpu's crystal - so you would gain better precision than normal SNES audio.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Bad Apple demo for SNES

Post by tepples »

The S-DSP supports setting the playback sample rate only in 7.8125 Hz increments.

It runs on my PowerPak, but there's some horrible rumbling while Marisa is on the broom.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Bad Apple demo for SNES

Post by 93143 »

That sounds like what no$sns does. It sounds to me like it's intermingling two different banks or something, and then restarting the one it was supposed to be playing (resulting in a desync); I assumed it was just the emulator because higan doesn't do it, and higan is usually more accurate. (The problem section also doesn't match up with the pops - I guess at least one of my suspicions is wrong...)

There's also a graphical glitch a couple of seconds in, that wasn't there in the silent version.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Bad Apple demo for SNES

Post by 93143 »

Saved 3 kB on the looped cymbal, without making it sound terrible. Total is now 51,399 bytes.

Again, the synth sample does not match the gain on the rest of the samples. Also note that even the rest of the samples do not necessarily match any given rip of the original audio (the video version is a bit louder than the CD version).
basamples_v2.1.7z
(46 KiB) Downloaded 235 times
I tried to sequence this in OpenMPT a while back, but the classic tracker timing just isn't precise enough; the hits don't even stay glued together for the first four bars. One could tweak the main track's playback speed, but over a three-and-a-half-minute song I can see that adding up to a video sync issue. Maybe I should take another look at it, but I suspect it may be better to write a simple driver first and sequence directly in hex without reference to a tempo...
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Bad Apple demo for SNES

Post by psycopathicteen »

I just found out a lot of time is spent waiting for vblank. It looks like using a frame queue was not as useful as I thought it would be.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Bad Apple demo for SNES

Post by 93143 »

You mean you wai after completing a frame? Does that mean you can speed it up by proceeding immediately to the next frame if there's a free slot, instead of waiting? Or does it already only wait after the queue is full?
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Bad Apple demo for SNES

Post by psycopathicteen »

It only waits when the queue is full, and it gets filled up pretty quickly.

I'm kind've fed up with streaming right now. I wonder if I can compress the audio to fit into 64kB by increasing the tempo 32 times faster, and then artificially slow it back down with channel fading.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Bad Apple demo for SNES

Post by 93143 »

Now that I think of it, waiting after every frame would simply not fill up the queue, and I've seen the full frame queue in the no$sns debugger. So I guess that was a silly thing for me to say...
I wonder if I can compress the audio to fit into 64kB by increasing the tempo 32 times faster, and then artificially slow it back down with channel fading.
Well, I just tried that approximate procedure with both Dirac and paulstretch, and uh, I suspect it's not going to work very well. I didn't exhaustively optimize (I was using a primitive Dirac implementation and had to use 5 passes each way, and paulstretch has at least one free parameter I didn't spend much time with), but from what I got it doesn't look promising:
basquash.7z
(1.38 MiB) Downloaded 256 times
I tried speeding it up with ADM Studio Time, but it tried to be clever about the re-expansion so I had to use paulstretch for that, and it didn't work any better. Using Studio Pitch (which is conceptually the same thing) produced a final result of the correct length, but it was still pretty bad; the 100% paulstretch one is the best result so far.

You've got to lose something when you compress, and if you're keeping the frequency information you lose time resolution. A really nice algorithm used well might produce something recognizable, but it wouldn't fool anybody.

...

Oh, hang on - are you transferring a constant amount of audio per frame? Maybe you could use the whole audio RAM as a buffer, and fill it up when you've got time... would that be easier than trying to make HDMA work? This would break my high-frequency augmentation scheme, but we can worry about that later (if you were ever worried about it in the first place)...

Re: HDMA, have you looked at the N-Warp Daisakusen source code?

...I hope my backseat driving isn't too offputting... I'm not the one who's been beating his head against this for months, so I'm still pretty enthusiastic about it...
Dr.Wily
Posts: 11
Joined: Thu Feb 02, 2012 7:05 am
Location: Skull Castle
Contact:

Re: Bad Apple demo for SNES

Post by Dr.Wily »

is there a nice guy which can patch the ROM file to test on tototek flashcart ? Thanks :wink:

EDIT : size is incorrectly detected by flasher program (2mb instead of 64)
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Bad Apple demo for SNES

Post by psycopathicteen »

psycopathicteen wrote:I think we can use a library of the 256 most used slivers. We can use this format for tiles:

IRIRIRIRIRIRIRIR
I: 0=indexed sliver, 1=literal sliver
R: 0=repeat sliver, 1=new sliver
Hey Tepples? You still have the compression codec? I found an optization.

If the sliver is being repeated, there doesn't need to be an "I" bit. Memory to memory shifts use a lot of cycles.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Bad Apple demo for SNES

Post by tepples »

In a packet with a skipped I bit, what is the empty bit used for?
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Bad Apple demo for SNES

Post by psycopathicteen »

It just pads the end with 0s, like this.

0000RRRRIRIRIR or
00000000RRRRRRRR
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Bad Apple demo for SNES

Post by tepples »

Like this?
Attachments
sba_skipibit.zip
With Skipped I bits
(3.48 MiB) Downloaded 202 times
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Bad Apple demo for SNES

Post by psycopathicteen »

It works, but it still didn't get rid of all the slowdown.

Indexed slivers take the longest to calculate so maybe there can be a limit to how many indexed slivers per frame.


EDIT: Screw it, it's close enough.

http://www.filehosting.org/file/details ... 0Apple.zip
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Bad Apple demo for SNES

Post by 93143 »

That's pretty good. Way more polished than last time, and the timing almost works even with the music at its original pitch. Little muffled; I see you've dropped the sample rate to 12 kHz...

I figure there are at least two methods still available to reduce the impact of the audio streaming without losing quality, but I mentioned both of them just upthread from here so I won't belabor the point. Combined with your suggestion that the video decoding speed could still be improved, it seems to me that there may be a decent amount of headroom left. I'm encouraged.

Again, I don't mean to rush you or harass you - it's great that you're doing this at all.

...

Could the encoder use some sort of complexity heuristic to determine when it's necessary to limit the number of indexed slivers, so as to minimize file size growth? Or would that be too hard to program and/or totally unnecessary? It just seems like there are only a couple of spots left that are still giving trouble...
Post Reply