NEStopia source indicates that it does not treat in-rendering PPU reads any different than out-of-rendering This is one of the more recent discoveries and was discovered after NEStopia 1.40 was released, so not surprisingly, NEStopia fails and glitches up during this game (near the end of level 1, when a cannonball hits the ground).įCEUX, somewhat surprisingly, emulates the game just fine without any glitching. I have no idea why, but the game apparently reads from the PPU I/O register ($2007) during rendering, which mangles the PPU address. Point goes to FCEUXĪnother edge case exposed by The Young Indiana Jones Chronicles. So yeah, NEStopia kind of fucks this up, and FCEUX does it right. But the emulation is there for anyone that wants it - just have to flip a switch. Since "old ppu" is the default in FCEUX, I don't know how many people actually use the new ppu. Though ultimately is appears to be a fluke that Micro Machines is working. I don't know if I'd call this a hack, as much as I'd call it a misrepresentation of the behavior. It's not exposing internal fetches as much as it's just exposing internal RAM. This is almost what it should be doing - but isn't quite right. Looking at the source, "old ppu" FCEUX doesn't even try to emulate this behavior: When "new ppu (slow!)" is selected, the shaking goes away. but only when "old ppu" is selected from the Config menu. FCEUX clearly glitches due to incorrect behavior here (screen shakes at the character selection screen). Micro Machines abuses this to find HBlank in order to do raster tricks. Reading from $2004 during rendering exposes the internal sprite fetches. I touched on this in the original thread. This is an edge case exposed by the game Micro Machines. I'm going to give NEStopia 2 points for this, since IRQ timing and cycle stealing are two different things. Rather than emulating the buffered sample fetch, it runs the DMC ahead a bit, then backtracks after the IRQ fires:Ĭpu.StealCycles( cpu.GetClock(cpu.IsWriteCycle(clock) ? 2 : 3) ) ĭma.address = 0x8000 | ((dma.address + 1U) & 0x7FFF) In this post, I am comparing Win versions of FCEUX 2.2.2 and NEStopia 1.40, which to my knowledge is the latest official release of each emu.ĭMC timing is very tricky, and a handful of Camerica games rely on reasonably strict DMC IRQ timing for split screen effects in some games, specifically Fire Hawk and the dreaded Mig-29 Soviet Fighter (one of the harder games to get working)īoth emus run the games correctly, but looking at the source, FCEUX cheeses it with a hack. But this might be fun and interesting nonetheless. This is far from an exhaustive list, and I am grossly oversimplifying by just assigning points to individual aspects. So did FCEUX catch up? Was I talking out of my ass? I decided to take a look into a lot of "gotchas" that plague NES emus which try to cut corners on accuracy. In that time, FCEUX has been in active development, while NEStopia has largely been idle.
In my reply I made some bold claims and pretty much said "zomg NEStopia is the greatest thing ever omgomgomg", but I realized that opinion came largely from the state of the emulators ~7 years ago. Snes9x-next and VBA-next are somehow more optimized so those games are emulated faster, but it has nothing to do with frameskipping.įrameskipping is the consequence of emulation speed, not the cause: some emulators try to fasten the speed by skipping the rendering of frame when needed, while Retroarch renders all frames in all cases, but if emulation speed is too low, the result is similar, some frames will not be displayed at the correct time (either dropped or repeated).Obscurumlux01 in another thread was curious about accuracy comparisons between FCEUX and NEStopia.
#Nestopia input lag plus
Genesis Plus GX standalone does not use frameskipping and runs faster than the Retroarch version (you can see it if you activate FPS display and frame throttle in both of them, I know because I tested it when it was added in genplus on googlecode).Īs for others GX emulators, I don't think you really understand how frameskipping works: they use automatic frameskipping, which means they ONLY skip frames if the emulation speed goes below the needed framerate, which only happens in some SNES games from time to time (those with special chipsin it. Genesis games surely run fullspeed for me, with no skipping or sound issues, be sure to use the last version of each emulators as well. It must be some configuration issue because all games I tried on homebrew emulators run fullspeed without any issues, besides a few SNES games that had frameskipping sometimes.