Star Fox End titles music is out of sync

[alyxx]

I was finishing up a playthrough of Star Fox on the hardest level in ZSNES when I noticed something odd. Sure Star Fox runs a lot more accurate now than in previous versions, but now it actually runs TOO slow for the end titles music. The end titles music finishes way before you get to the "The End" logo thing.

[franpa]

already known.

[alyxx]

I just couldn't find any topic for it, using the search function. Is there any way to fix this?

[byuu]

Very doubtful.

Even having cycle-perfect timing with clock-level synchronization, emulating the 256-byte instruction cache, emulating both the primary and secondary pixel caches, emulating the ROM and RAM access caches, and emulating the multiplier speed select setting aren't enough to get these games to finish the songs when they should.

I don't know what else we can even try at this point.

[alyxx]

Well, the game itself is emulated very good now, so it is only a minor flaw.

Besides, I do have the real cartridge on real hardware, just not where I live at the moment, so the emulator is more a temporary replacement for me until I can play the real thing again.

[Squall_Leonhart]

Very doubtful.

Even having cycle-perfect timing with clock-level synchronization, emulating the 256-byte instruction cache, emulating both the primary and secondary pixel caches, emulating the ROM and RAM access caches, and emulating the multiplier speed select setting aren't enough to get these games to finish the songs when they should.

I don't know what else we can even try at this point.

Whats the chance this game actually uses spu timing to properly sync up.

[grinvader]

Except SPU timing is already cycle accurate.


Please insert coin.

[Squall_Leonhart]

Except SPU timing is already cycle accurate.


Please insert coin.

Don't talk in absolutes. There is always a chance of an irregularity in the spu timing, especially when the Cart itself extends the capability of the console using its special chips n shit.

[Truth Unknown]

Super FX has done nothing for the sound portion of the game. EDITOne could say that the emulation of the Super FX chip is slowing down the game visually but not audibly though.

[grinvader]

Don't talk in absolutes. There is always a chance of an irregularity in the spu timing, especially when the Cart itself extends the capability of the console using its special chips n shit.

You know nothing. Just writing that is enough proof. Don't try to teach people stuff or what not to do when you know shit about the topic, it makes you look seriously retarded.

[spiller]

I've noticed Snes9x has a similar problem. The graphics run too fast. It's very obvious during the initial exiting of the hanger on Corneria and a few other heavy graphics places. What actually causes it? What is it about the SuperFX that makes it hard to emulate the speed precisely?

[Exophase]

I've noticed Snes9x has a similar problem. The graphics run too fast. It's very obvious during the initial exiting of the hanger on Corneria and a few other heavy graphics places. What actually causes it? What is it about the SuperFX that makes it hard to emulate the speed precisely?

All those things byuu mentioned. It's harder to perfect the timing of a more complex chip that is pipelined and has caches/write buffers. Not to say that it isn't difficult to get the timing down perfectly of the chips inside the SNES.

There's also another aspect that byuu didn't mention, and that's that the timing model of these sorts of games can be very different from your typical SNES game. Most SNES games, and most 2D games in general, synchronize events per-frame (or in some cases per-line, but on SNES a lot of this happens independently of the CPU). Because of this, if you make things take a pretty wildly different number of cycles than they do on the real thing you will very often still get the correct results so long as you don't give too few cycles. That's because it's pretty easy to synchronize those simple events with real time on the computer you're emulating on, and then the game just waits for those events to happen.

3D games, on the other hand, will to the best of their capability and as much as hardware permits tend to start drawing the next frame as soon as it has finished drawing the last one, in order to get a steady stream of frames going. At the very least this is the case when rendering a scene takes much longer than the update rate of the screen, which is certainly the case for Star Fox. Usually this just means a better frame rate/smoother visuals, because in-game events will still occur based on real world time (either by, again, counting vsyncs or some other guaranteed periodic timer). But sometimes it might have a fixed number of frames to play for something for whatever reason and it can affect synchronization of events. This can at least be true where user-input doesn't matter, like at the end of Star Fox. Either way, you can see how it's a lot harder to get things exactly the same as the real machine in these cases.

[Squall_Leonhart]

Don't talk in absolutes. There is always a chance of an irregularity in the spu timing, especially when the Cart itself extends the capability of the console using its special chips n shit.

You know nothing. Just writing that is enough proof. Don't try to teach people stuff or what not to do when you know shit about the topic, it makes you look seriously retarded.

Grinvader. go and get the cock you need, seriously. Your constant PMS'ing brings the entire board down.

[Deathlike2]

I lol @ the defiance.

[JailDesigner]

if i can help, i remember playing StunRace FX with the internal camera, so the snes hasn't to draw the car. I blow all the records that way because the game was a lot faster. That was a poor programing implementation of the clock game or else

Keep up the good work, guys!