Quote:
I don't use v1.51 because of it shows all 224 lines and the bottom one on some of the games really stands out and is very annoying.
Line 224 should be there, the system does render it. In ~50% of games, the data there is valid, and in ~99% of games, it blends in fine. There's a bug in ZSNES where it shows the wrong data there, though. Noticeable in most games.
Nobody's ever complained that I render it.
Quote:
But what do you guys think of bsnes in comparison to the big two?
It sucks. Very slow, no savestates, no netplay, no movie features, no SuperFX or SA-1 support; and its license is too restrictive due to a paranoid author.
Quote:
I trought that SNES9x had supperior audio but maybe that changed. "Noise" isn't played loud engough and this changes sound effects significanly in some games.
You may prefer Snes9X' audio, especially with artificial enhancements such as cubic interpolation, but it's never been closer to the hardware. At first, I used anomie's core, which was Snes9X / OpenSPC + many improvements. But for the past year or two now, I use blargg's S-DSP emulator, which is cycle-based and bit-perfect sans a slight pulse when you mute channels. SNES audio volume is just really low in general.
ZSNES v2 will have the same S-DSP core.
Quote:
(What is, and what isn't emulated...)
http://byuu.cinnamonpirate.com/bsnes/errata/http://byuu.cinnamonpirate.com/articles/emulation/ -- read the "What does no hacks mean?" section, the rest is background noise.
Executive overview:
S-CPU is nearly perfect. The only noticeable differences are:
- CPU rev. 1 HDMA crashing bug not supported
- Auto-joypad polling delay not supported
- Reading mul / div registers early doesn't return partially computed data
No software could make use of these bugs, so they don't affect games, at least.
S-SMP is also nearly perfect, except the timer glitch before the mini-SNES is not supported, and the TEST register won't crash the system like it does on the real thing. Again, no games use that, as it's not a very useful effect to crash the system.
S-DSP is bit-perfect sans channel mute. I didn't do any of this work though, it was all blargg's research and code.
S-PPU is a hacked up piece of shit. It's a scanline renderer. Although it does emulate all known hardware features, as well as bugs and quirks that nobody else does: $2100 OAM reset, interlace sprite height glitch, etc. We get lucky in that few SNES games need cycle renderers, whereas many NES games do. No SNES emu goes beyond scanline yet.
Aside from the S-PPU, they all use the lowest possible level of timing, including even cycle-level bus hold delays. Every CPU and SMP opcode whose cycle-level timings could be verified by tests have been. CPU by myself and anomie, SMP by blargg.
You can think of bsnes as Nintendulator with NESticle's PPU renderer.
So really, we need to rewrite the S-PPU, add a half-dozen hardware glitches, and it'll be 99.99% as good as you can ever possibly get from emulation. Then we just need to make it all fast. Eg Snestopia. What do you say, Marty? ;)
Quote:
I've noticed a huge difference between the triforce intro in Zelda for the SNES between Snes9x + bsnes and ZSNES. Check it out.
That's due to timing. For some reason, most people seem to think ZSNES is more accurate than Snes9X. In truth, it's just more stable. '9x has a lot of out-of-bounds memory errors that crash the thing (eg MMX3) due to overly-aggressive and dangerous optimizations (passing lots of raw pointers around and such.)
I always get my tests bit-perfect in my own emulator, and they're usually relatively close with every other emulator. But with ZSNES v1.51 and earlier, the results are off in center field. It's basically overclocked by ~20-30% in most cases, as that helps overall compatibility when timing is bad. And that's why those triforces swing together so quickly.
ZSNES v2 is supposed to address the timing issues with CPU+SMP, and use blargg's DSP, so it should be a lot better.