Romhacking.net

Romhacking => Programming => Topic started by: Disch on October 15, 2015, 01:54:38 pm

Title: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: Disch on October 15, 2015, 01:54:38 pm
obscurumlux01 in another thread was curious about accuracy comparisons between FCEUX and NEStopia.

The link is here:
http://www.romhacking.net/forum/index.php/topic,20530.msg288751.html#msg288751

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.  In that time, FCEUX has been in active development, while NEStopia has largely been idle.

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.

This is far from an exhaustive list, and I am grossly oversimplifying by just assigning points to individual aspects.  But this might be fun and interesting nonetheless.


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.

DMC IRQs and DMC Timing

Reference:
http://wiki.nesdev.com/w/index.php/APU_DMC#Memory_reader

DMC 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)

Both emus run the games correctly, but looking at the source, FCEUX cheeses it with a hack.  Rather than emulating the buffered sample fetch, it runs the DMC ahead a bit, then backtracks after the IRQ fires:

FCEUX | sound.cpp | 564
Code: [Select]
   /* Unbelievably ugly hack */
   if(FSettings.SndRate)
   {
    soundtsoffs+=DMCacc;
    DoPCM();
    soundtsoffs-=DMCacc;
   }
(I did not add that comment, that is actually in the source)

FCEUX also does not appear to halt the CPU (or "steal cycles") for the DMA performed by the DMC.  NEStopia on the other hand, not only steals cycles, but properly steals a variable amount depending on the CPU state at the time of the DMA, in addition to properly buffering the DMA'd value:

NEStopia | NstApu.cpp | 2113
Code: [Select]
if (!readAddress)
{
cpu.StealCycles( cpu.GetClock(cpu.IsWriteCycle(clock) ? 2 : 3) );
}
else if (cpu.GetCycles() != clock)
{
cpu.StealCycles( cpu.GetClock(3) );
}
            ...
dma.buffer = cpu.Peek( dma.address );
cpu.StealCycles( cpu.GetClock() );
dma.address = 0x8000 | ((dma.address + 1U) & 0x7FFF);
dma.buffered = true;


I'm going to give NEStopia 2 points for this, since IRQ timing and cycle stealing are two different things.

2 Points go to NEStopia


OAM Reads during Rendering

Reference:
http://wiki.nesdev.com/w/index.php/PPU_sprite_evaluation

This is an edge case exposed by the game Micro Machines.  I touched on this in the original thread.

Reading from $2004 during rendering exposes the internal sprite fetches.  Micro Machines abuses this to find HBlank in order to do raster tricks.  FCEUX clearly glitches due to incorrect behavior here (screen shakes at the character selection screen)... but only when "old ppu" is selected from the Config menu.  When "new ppu (slow!)" is selected, the shaking goes away.

Looking at the source, "old ppu" FCEUX doesn't even try to emulate this behavior:
FCEUX | ppu.cpp | 648
Code: [Select]
} else {
FCEUPPU_LineUpdate();
return PPUGenLatch;
}

HOWEVER... "new ppu" FCEUX does in fact emulate this behavior.  It's on line 526 of ppu.cpp, and I won't paste the code here since it's massive.


NEStopia, while it plays the game properly, appears to only be emulating the behavior half-way:

NEStopia | NstPpu.cpp | 870
Code: [Select]
if (!(regs.ctrl[1] & Regs::CTRL1_BG_SP_ENABLED) || cpu.GetCycles() - (cpu.GetFrameCycles() - (341 * 241) * cycles.one) >= (341 * 240) * cycles.one)
{
io.latch = oam.ram[regs.oam];
}

This is almost what it should be doing -- but isn't quite right.  It's not exposing internal fetches as much as it's just exposing internal RAM.  I don't know if I'd call this a hack, as much as I'd call it a misrepresentation of the behavior.  Though ultimately is appears to be a fluke that Micro Machines is working.


Since "old ppu" is the default in FCEUX, I don't know how many people actually use the new ppu.  But the emulation is there for anyone that wants it --- just have to flip a switch.

So yeah, NEStopia kind of fucks this up, and FCEUX does it right.   Point goes to FCEUX



PPU Reads during Rendering

Reference:
http://forums.nesdev.com/viewtopic.php?p=62827#p62827
http://wiki.nesdev.com/w/index.php/Reading_2007_during_rendering#Output

Another edge case exposed by The Young Indiana Jones Chronicles.  I have no idea why, but the game apparently reads from the PPU I/O register ($2007) during rendering, which mangles the PPU address.  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).

FCEUX, somewhat surprisingly, emulates the game just fine without any glitching.


NEStopia source indicates that it does not treat in-rendering PPU reads any different than out-of-rendering
NEStopia | NstPpu.cpp | 967
Code: [Select]
NES_PEEK_A(Ppu,2007)
{
Update( cycles.one, address );

NST_VERIFY( IsDead() );

address = scroll.address & 0x3FFF;
scroll.address = (scroll.address + ((regs.ctrl[0] & Regs::CTRL0_INC32) ? 32 : 1)) & 0x7FFF;
UpdateScrollAddressLine();

io.latch = (address & 0x3F00) != 0x3F00 ? io.buffer : palette.ram[address & 0x1F] & Coloring();
io.buffer = (address >= 0x2000 ? nmt.FetchName( address ) : chr.FetchPattern( address ));

return io.latch;
}

'IsDead' checks to see if rendering is disabled.  NST_VERIFY just seems to log something -- it doesn't actually change flow.  Proper behavior here would be to put everything after the NST_VERIFY line in a 'if( IsDead )' block, and 'else' that with code addressing the weird behavior.


FCEUX is employing a hack... sort of.  It's questionable to say the least:

FCEUX | ppu.cpp | 243
Code: [Select]
if (rendering)
{
//don't do this:
//if (by32) increment_vs();
//else increment_hsc();
//do this instead:
increment_vs();  //yes, even if we're moving by 32
return;
}

FCEUX, unlike NEStopia, does in fact acknowledge that behavior is different when rendering, but it doesn't even try to get the proper behavior right.  The logic here is a lot more complex than simply incrementing the PPU addr by 32 (as illustrated on the wiki page http://wiki.nesdev.com/w/index.php/Reading_2007_during_rendering#Output ).  So it's kind of a fluke that this works at all.

It would be interesting to date this code to see if it was written before or after the post on the nesdev forums outlining this behavior.  But just from looking at it, I can't help but think the developer just said "whatever, this fixes that game so it's good enough".

On one hand you could argue this is a hack.  On the other hand you could argue it's just incomplete.  I'll be kind and give FCEUX devs the benefit of the doubt and just say it's incomplete.  And FCEUX does in fact run the game where NEStopia chokes.  So while neither emu does it right, FCEUX at least sort of does it.

Point goes to FCEUX



Rendering when Rendering is disabled

(Can't find a reference for this on the wiki -- sorry)

When rendering is disabled, the PPU will usually draw the backdrop color ($3F00) to the screen.  However, if the PPU address lies in palette space, then whatever palette entry it points to will be drawn instead.

Micro Machines relies on this behavior to draw bars with a fancy gradient.  FCEUX does not draw these bars properly, and also has splashes of black scanlines on the title screen that shouldn't be there.  NEStopia properly renders the game without issue.

In the source, NEStopia is properly checking to see if the address lies in palette space, and uses the pointed to value if so -- otherwise defaults to the backdrop.

NEStopia | NstPpu.cpp | 2627
Code: [Select]
HActiveOff:
{
const uint pixel = output.palette[(scroll.address & 0x3F00) == 0x3F00 ? (scroll.address & 0x001F) : 0];

To be honest, I am having all sorts of difficulty finding the relevent code in FCEUX.  The only rendering code I can find makes no distinction between whether or not rendering is enabled -- which I assume means the emu checks that before the routine is called, but I can't find where it actually does that -- the rendering code is all over the place and pretty unorganized.  I've been looking for ~20 minutes and I can't find it.


Regardless, NEStopia is doing it right, and is emulating the game properly.  FCEUX has glitches, so whatever it's doing, it must be doing it wrong.

Point goes to NEStopia




I think that leaves it at NEStopia: 3, FCEUX: 2.

There are other things I want to check but I need a break.  So I'm going to stop for the time being.  I'll come back to this later.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: Pennywise on October 15, 2015, 03:11:41 pm
I thought this was a moot point because puNES is the most accurate NES emulator. Also, I think Bizhawk's NES emulation core is also better than FCEUX.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: Disch on October 15, 2015, 03:15:10 pm
Shows how long I've been gone.  I don't know anything about puNES.


EDIT:

Yeah puNES pretty much looks like the Bee's Knees.
Title: .
Post by: Chpexo on October 15, 2015, 06:52:11 pm
.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: dougeff on October 15, 2015, 06:54:08 pm
Also (I think), neither one uses all of MMC5 features correctly. Though I can't think of any games this effects.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: Jorpho on October 15, 2015, 11:27:45 pm
The most obscure thing I can think of is a glitch used in a Mega Man TAS for skipping a stage that apparently depends on very specific PPU behavior.
Quote
DelayStageClear is impossible with NewPPU of FCEUX,debbuger of Nintendulator but DelayStageClear is possible with OldPPU of FCEUX, Nestopia, Nintendulator. Mr.Inzult tested this by using PowerPak with a real NES. In a word, DelayStageClear in the BombManStage is possible also in real NES! (OldPPU of FCEUX is proven to be correct.)
http://tasvideos.org/2921S.html
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: obscurumlux01 on October 16, 2015, 02:57:12 am
I love this thread so much right now.
Disch you don't need to dig in further if you don't feel like it (unless you actually want to do so).
I greatly appreciate the references and thorough explanations of things.

To be honest, it will take me a few days to really parse things and read up enough on it to understand the coding aspect of it (this is why I'm not a programmer heh).  Those references will help ^_^
But I can understand the general logic of it even if the exact syntax stuff escapes me.

So since others have chimed in, how about a reasonable consensus?  What is the most accurate NES emulator out right now and how well does it perform?
If Nestopia isn't the best of the best anymore then I'm still waiting for an answer on 'best NES emulator'  ^_^
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: Disch on October 17, 2015, 10:51:42 pm
Initial impressions of puNES is that it is exemplary.

Checking the source for puNES would be difficult, as it's not in English  =(
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: obscurumlux01 on October 18, 2015, 04:06:09 pm
I'll give puNES a look.
What parts of the source aren't in English? (https://github.com/punesemu/puNES)  I looked through briefly and couldn't find non-english other than the descriptions on the GitHub page (which aren't part of the source code itself but just descriptions).
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: Disch on October 18, 2015, 06:43:48 pm
Bah.  I guess the bulk of it is in English.  Maybe I just saw the github comments, as well as in-code comments and it messed with my brain.

Yeah the actual function and var names do seem to be in English.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: obscurumlux01 on October 23, 2015, 09:17:00 pm
Just a quick update.
Found some test results for various emulators here (http://tasvideos.org/EmulatorResources/NESAccuracyTests.html) along with full technical details on what tests they pass/fail and why.

Would love to hear feedback and thoughts on these results and what they mean for NES/Famicom emulation going forward.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: chillyfeez on October 24, 2015, 09:30:42 am
Has anyone ever done this sort of analysis with SNES emulators?
I recently discovered a bit of glitchiness in my project (it has to do with dialogue boxes in FFIV), but the manifestation of the glitch varies depending on the emulator. I've figured out ways to mitigate the issue, but it would help my peace of mind to know that what I'm doing to "fix" (hide) it would translate to actual SNES hardware (as I don't currently have the means to test it myself on actual SNES hardware).
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: Jorpho on October 24, 2015, 12:15:23 pm
but the manifestation of the glitch varies depending on the emulator.
The general consensus seems to be that if you're seeing it in ZSNES you should probably forget about it.
Title: Re: Emu Accuracy analysis
Post by: obscurumlux01 on October 24, 2015, 06:47:12 pm
Well maybe we should rename the thread to just be a general 'emu accuracy analysis' thread :)
While the TAS (tool assisted speedrun) community prefers a particular emulator for the tools it provides to assist in speedruns, that doesn't mean they always choose the most accurate emualtors.

For SNES, the primary information (http://nonmame.retrogames.com/) I could find seems to be Higan as high-accuracy and cycle-accurate, then SNES9X being medium accuracy and tolerable, then everything else either being equal to SNES9X or worse.  ZSNES is so bad that almost everyone has already migrated away from using it as a standard in their ROM hacks.  RetroArch using the bsnes accuracy/balanced/performance cores helps to mitigate usability problems and let people just enjoy the games without messing with importing and libraries and crap.

The sad thing is that a high-profile ROM hack like Crimson Echoes mentions 'this plays best on ZSNES' despite that no longer being true for over 2 years now.  CE has been fixed to no longer require the buggy sound core of ZSNES to play songs properly and yet it still has that message.

For the Sega Systems, the closed-source Kega Fusion still wins by leaps and bounds over others (plus native 32x support that is better than any other).  Others come close but Kega Fusion is the only one so far that has everything in one go.

The RetroArch information is the most comprehensive that I could find, but keep in mind that it is outdated by at least a year (if not longer) due to the progression of emulators and technology.  Maybe we need to crowdfund a comprehensive emulator analysis and comparison to the actual NES system (with physical non-flash NES test cartridges for comparison).
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: chillyfeez on October 24, 2015, 10:13:26 pm
Cool. Thanks!
Title: Re: Emu Accuracy analysis
Post by: Dr. Floppy on October 25, 2015, 03:19:39 am
Maybe we need to crowdfund a comprehensive emulator analysis and comparison to the actual NES system (with physical non-flash NES test cartridges for comparison).

Is there a crowdfund for a FCEUX/xD SP-quality debugging utility for SNES?

(I'll volunteer as the crowd.)
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: Rodimus Primal on October 28, 2015, 09:24:49 am
I've been told PUNes was the most accurate, but I wonder if accurate also means having bad input lag. Nestopia doesn't give me the same issues input wise.

Higan's GUI and filing system bothered me so bad I went SNES9x and never went back. That and ZSNES has been surpassed for years now.

I don't care for the fuzzy screen on Kega, but it works and works well.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: obscurumlux01 on October 28, 2015, 08:25:22 pm
I've been told PUNes was the most accurate, but I wonder if accurate also means having bad input lag. Nestopia doesn't give me the same issues input wise.
Higan's GUI and filing system bothered me so bad I went SNES9x and never went back. That and ZSNES has been surpassed for years now.
I don't care for the fuzzy screen on Kega, but it works and works well.

I've seen that puNES has one fatal flaw (in my eyes) which is the inability to PAUSE a currently emulated game.  There's no pause function!  Only power (hard reset) and reset (soft reset) are available.

On the audio front, I'm happy to report that we now have emulated STEREO SOUND for the NES.  It sounds AMAZING!  I use Ninja Gaiden as an example and holy cow.  It really is like how it feels when putting on surround sound headphones for the first time.  Just WOW.
I say that puNES seems to have the most accurate and pitch-perfect audio and audio sync of any emulator I've ever experienced!
I can say this with 99.9% confidence for Ninja Gaiden 1, Final Fantasy 1, Super Mario Bros 1/2/3, Contra, SuperC, and The Legend of Zelda.
Those are the games I played in my early childhood for a combined total of hundreds of hours (especially FF1 and SMB3 in the pre-internet days).
I clearly still remember the tunes; some say I have an ear for music.  :)

As for video, I've had no issues with it so far even though the lack of documentation lead to lots of experimenting with how things work.  The video options include a wide variety of filters, an interpolation toggle (doesn't say what kind of visual interpolation is used), and under 'Pixel Aspect Ratio' it has an 'HLSL soft stratch' toggle option.  From what I can tell, both the interpolation and HLSL soft stretch options just make things more blurred to mitigate jaggy pixels.  When sitting about one or two meters away from the screen, the effect is very nice and still affords decent readability of in-game text.

I've had zero input lag with puNES and this is with both Ninja Gaiden 1 and Megaman 2.  If you know those games you know that precise input is absolutely critical.  Zero issues (although I do play with a gamepad so that may be something).  You have to remember that you are meant to play emulated games with a gamepad rather than on the keyboard.  Most consumer-quality and non-mechanical keyboards are not designed for gaming and you run into the often-complained FAQ regarding Chrono Trigger and certain button combinations to open a door or passageway.

SNES9X is fantastic but still uses many game-specific hacks to get things to work; ZSNES is still piss-poor by comparison as far as emulation quality, updating, and accuracy.  The difference is SNES9X team has accepted accuracy-related fixes from byuu and other contributors while ZSNES has declined such improvements and their GitHub has been completely stagnant for a while.  They are 'working' on a major revamp update but have given absolutely no indication or public information about it outside of a post or two on their forums.
I also hated the Higan folder-based system and saw that RetroArch presumably has a Higan-based setup WITHOUT the folder crap.  You could possibly give that a try if you want to ^_^

KEGA Fusion has a fuzzy screen?  What!?  Have you looked through the options?

Go to your Video menu and do the following:
-No Scanlines
-Normal unfiltered output
-Fixed Aspect Ratio (Fit)
-Nearest Multiple (optional but recommended)
-Uncheck the 'Filtered' option (Filtered = Interpolation = Fuzzy/Blurry screen)
-Brighten (optional but recommended)
-Use NTSC Aspect (optional but highly recommended)

Hope that helps!
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: Rodimus Primal on October 29, 2015, 08:58:15 am
I agree with you that the sound is better on puNES. The input lag I get is from Super Mario Bros 1 and 3. I play with a PS2 controller plugged into my PC via USB and Nestopia handles it well. But puNES I notice the jumps take a split second longer to register and I get killed even in 1-1!

For the longest time I was using bsnes and I even took the time to take screenshots of the titlescreens, make folders ending in .sfc and placing the ROMs, save files, states, etc in them. Then I ran into a major bug with Donkey Kong Country (1.0). I had an .smc file that snespurify converted to .sfc and it created a bug. If you used the BARRAL code and then get hit by an enemy, the screen went blank. I never liked the newer versions of bsnes, now Higan, and the straw that broke the camel's back was the fact that the new library system COPIES your Roms and creates its own folder system seperate from your existing ROMS. Granted that in today's day and age hard drive space is not really a concern but its still a waste of space. I took all of my ROM files out of that crappy folder system, made my own system and went to using SNES9x.

What I mean in Kega Fusion is the screen when you first load it up. It's like turning on an old TV to channel 3 with the scrambled white snow. It's cool the first time you see it, but its annoying the more you use the emulator.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: KingMike on October 29, 2015, 10:47:32 am
I couldn't reproduce the DKC error (using higan 094 accuracy).
Maybe it was just your ROM.
All snespurify is doing really is removing the header (if present) and changing the extension. Maybe deinterleaving but I suppose interleaving is technically a bad dump in the first place.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: obscurumlux01 on October 29, 2015, 03:40:49 pm
The input lag I get is from Super Mario Bros 1 and 3. I play with a PS2 controller plugged into my PC via USB and Nestopia handles it well. But puNES I notice the jumps take a split second longer to register and I get killed even in 1-1!

Then I ran into a major bug with Donkey Kong Country (1.0). I had an .smc file that snespurify converted to .sfc and it created a bug. If you used the BARRAL code and then get hit by an enemy, the screen went blank. I never liked the newer versions of bsnes, now Higan, and the straw that broke the camel's back was the fact that the new library system COPIES your Roms and creates its own folder system seperate from your existing ROMS

What I mean in Kega Fusion is the screen when you first load it up. It's like turning on an old TV to channel 3 with the scrambled white snow. It's cool the first time you see it, but its annoying the more you use the emulator.

This has been a very interesting discussion, heh.

1 - I still get zero input lag after extensive testing with Super Mario Bros 1, 2, and 3.  I'm starting to think it is your controller rather than puNES.  Perhaps Nestopia has some kind of input library that takes odd controllers into account and compensates for it.  Dunno exactly.  You said you're using a PS2 controller but is it an official Sony PlayStation 2 Dual-Shock or is it one of those Chinese-made generic lookalikes?
I'm using a standard Logitech 'Precision' Gamepad.  Like $10 USD at most stores.  I got mine for free from my older bro but you can still find them.  They're really fantastic for pre-analog gaming.
For post-analog gaming I use a Logitech F310 gamepad.  Really good sturdy build quality and large enough for my huge hands.  It can take a beating, but it is better not to abuse your gamepads.  It is really easy to find and I got mine at a Walmart (US-based discount item retailer) for like $25 USD with free in-store pickup.
You could just use the F310 for both, but I don't feel right playing an 8-bit or 16-bit game with analogs.  But that's just me :)
Neither one of those Logitech gamepads require me to install special drivers or recalibrate things.  Just plug and play.

2 - Tested your bug with the latest v0.95 version of Higan; couldn't replicate it.  And yeah I hate how the library system works but it is supposedly to make up for all the interleaved/deinterleaved or header/nonheader roms.  Unfortunately if you do this then you still have to keep an original ROM backup and it is double the space but meh.

3 - I know what you're talking about.  You're using an older or non-Windows version of Kega or Kega Fusion.  The latest version is v3.64 released on March 6 of 2010 by Steve Snake (http://www.carpeludum.com/kega-fusion/).  That link is his official website where you can get it.  If you are using Windows 8 or 8.1 then you need this version (http://www.emucr.com/2014/10/kega-fusion-v364-60fps-fix.html) so your emulator will run at 60 FPS in full screen mode (otherwise it is locked to 30 FPS).  If you are on Windows 10 there have been reports that it doesn't even run in full-screen mode even with that 60 FPS fix.
Yet another reason to stay with Win7 ;)
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: Rodimus Primal on October 30, 2015, 01:52:38 pm
I'm using two official PS2 controllers plugged into an adapter. I have no issues with any other program with them. I even use Xbox360ce with them so that games on Steam work (had a blast with Double Dragon Neon and Transformers Devestation!). I really don't like the Logitech D-Pads on controllers. They aren't great for diagonals which makes fighting games a challenge to pull of special moves. It's almost like using the transforming D-Pad on the X-box 360 controller in that it's not quite right even though they try.

The version of bsnes I used was V073. I'm sure there have been improvements since then, but the horrid and unconfigurable library system with each version since and the removed features in the GUI have been reasons I've stuck to my guns. It happened when I used the snespurify tool that came with THAT version of bsnes to convert my ROMS from .smc to .sfc. The problem is in the conversion to .sfc. Higan 0.95 doesn't quite do that. Also, Higan doesn't compensate for the overscan area so in full screen the game area is smaller than it should be. It's like watching a widescreen movie from a DVD before anamorphic widescreen (tiny rectangle in the middle of my TV). That was implemented back in V088 and byuu said he will not change or fix it. I would always try out the new version of bsnes even up to the name change to Higan, but I find SNES9x does everything I need it to do.

I've been using 3.64 of Kega Fusion. I did a Google seach last night to discover that you can turn TV static off in the .ini file. All you have to do is change it from 0 to 1. I'm using Windows 10 and told it to run Kega in compatibility mode with Windows 7. There are no issues that I've had with full screen with it set that way. Since I use the right click for the menu to change games or exit, I never have to leave full screen to run it.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: MeganGrass on October 30, 2015, 08:09:16 pm
The dedication to accuracy that byuu has put into bsnes has always interested me and definitely will always have my utmost respect. His work on special chips is still an amazing accomplishment that I will always adore.

Rather unfortunately, everything became a mess when the file/folder thing was forced upon everyone; It's completely unnecessary and inconvenient. To make matters worse, everyone who has voiced their disliking of that "feature" is typically met with a "fuck off" type of response. Stop trying to make fetch happen, it isn't going to happen.

On top of that, you're practically forced to use an external app (snespurify) to manage your rom data before you can even boot a ROM in the emulator for the first time.

Accuracy doesn't matter in emulators when one has to jump through hoops to get the darned thing to boot... and not that it matters in terms of usability, but the "bsnes" title is infinitely better than "higan".


I hate that I have these complaints, I really just wish the emulator wasn't a hassle to use.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: SunGodPortal on October 30, 2015, 09:18:20 pm
Quote
The dedication to accuracy that byuu has put into bsnes has always interested me and definitely will always have my utmost respect. His work on special chips is still an amazing accomplishment that I will always adore.

Rather unfortunately, everything became a mess when the file/folder thing was forced upon everyone; It's completely unnecessary and inconvenient. To make matters worse, everyone who has voiced their disliking of that "feature" is typically met with a "fuck off" type of response. Stop trying to make fetch happen, it isn't going to happen.

On top of that, you're practically forced to use an external app (snespurify) to manage your rom data before you can even boot a ROM in the emulator for the first time.

Accuracy doesn't matter in emulators when one has to jump through hoops to get the darned thing to boot... and not that it matters in terms of usability, but the "bsnes" title is infinitely better than "higan".


I hate that I have these complaints, I really just wish the emulator wasn't a hassle to use.

Sounds like I'll never be using it then. I just want to play and hack games. I don't want that experience to be ruined by what seems like the author's bizarre and unhealthy fixation on something that's been taken to an illogical extreme to the detriment of the user.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: MeganGrass on October 30, 2015, 09:38:31 pm
Sounds like I'll never be using it then. I just want to play and hack games. I don't want that experience to be ruined by what seems like the author's bizarre and unhealthy fixation on something that's been taken to an illogical extreme to the detriment of the user.

Please, don't let my opinion prevent you from at least trying it. Seriously.

It's a most excellent emulator! ...it just isn't user-friendly, at all.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: obscurumlux01 on October 30, 2015, 10:04:42 pm
I'm using two official PS2 controllers plugged into an adapter. I have no issues with any other program with them. I really don't like the Logitech D-Pads on controllers. They aren't great for diagonals which makes fighting games a challenge to pull of special moves.
I've been using 3.64 of Kega Fusion. I did a Google seach last night to discover that you can turn TV static off in the .ini file. All you have to do is change it from 0 to 1. I'm using Windows 10 and told it to run Kega in compatibility mode with Windows 7. There are no issues that I've had with full screen with it set that way. Since I use the right click for the menu to change games or exit, I never have to leave full screen to run it.

For KEGA, I found the item to change in the INI file:  StaticDisabled=1
I didn't realize that I'd already changed this a while ago and just forgot about it.  ^_^
I have a feeling the adapter you are using is not fully supported/compatible with puNES for some reason.  Not sure why.  I've had no issues with Logitech D-Pads but I understand people have their own preferences.

The dedication to accuracy that byuu has put into bsnes has always interested me and definitely will always have my utmost respect. His work on special chips is still an amazing accomplishment that I will always adore.
Rather unfortunately, everything became a mess when the file/folder thing was forced upon everyone; It's completely unnecessary and inconvenient. To make matters worse, everyone who has voiced their disliking of that "feature" is typically met with a "fuck off" type of response. Stop trying to make fetch happen, it isn't going to happen.
On top of that, you're practically forced to use an external app (snespurify) to manage your rom data before you can even boot a ROM in the emulator for the first time.
Accuracy doesn't matter in emulators when one has to jump through hoops to get the darned thing to boot... and not that it matters in terms of usability, but the "bsnes" title is infinitely better than "higan".

The thing with byuu is they always march to the beat of their own drummer.  That's just how it goes; their emulator their rules in a way.  Not that I agree with it but that is how they decided to do it.  They never made Higan for the community; it was always a personal passion project.  I find it ironic that byuu expects the wider emulation community to adopt Higan as a standard when he's so openly hostile to anyone that doesn't agree with them.

I also am thankful for and admire their dedication to accuracy and special chips.  The information that byuu and 'Doctor Decapitator' were able to obtain on the various special SNES cartridge-chips is absolutely priceless.  The good Doc was the one who did work that is worth millions of dollars in time and labor for just the cost of materials/parts (http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator/3/).

The external app thing consists of 'icarus' which is bundled with Higan v0.95 on byuu's website.  Does basically the same stuff as snespurify plus organizes things so the emulator can find the files.

As for the change from bsnes, I believe it was a trademark issue and wanting to avoid infringing on Nintendo trademarks.  It has been a while since I visited byuu's forum but that discussion may still be archived somewhere.

I wouldn't recommend Higan for casual users to use.  I'd recommend SNES9X instead.  Higan is made exclusively for accuracy-enthusiasts who have the hardware and technical know-how to deal with the quirks of using it and configuring everything properly.  They also have to be willing to not bother sending suggestions to byuu and stick purely with noting bug reports if they want to contribute to development (or fork the code if they can do programming).

People can complain about Higan but it is under GPL so just fork it and stick it up on GitHub and change the stupid UI/folder system to something better.  Perhaps use the 'Performance' core by default and integrate all 3 cores as a menu option instead of seperate executables.

As I posted earlier, RetroArch supposedly has a version of Higan that fits these criteria and I'll be looking into it if I ever have to play those games that would benefit from it.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: SunGodPortal on October 30, 2015, 11:21:12 pm
Quote
Please, don't let my opinion prevent you from at least trying it. Seriously.

It's a most excellent emulator! ...it just isn't user-friendly, at all.

Actually now that I think about it, I only use a SNES emulator when I test my hacks or when playing weird hacks that won't work on real hardware. ZSNES does everything that I need it to so I guess I'll just keep using it. An accurate emulator for something other than NES or SNES would be more interesting for me as I tend to just play those games on real hardware but emulate other things like handheld systems that I will likely never buy.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: KingMike on October 31, 2015, 01:25:27 am
My guess is the name bsnes was changed when the emulator became a multi-system emulator and the name no longer seemed appropriate.
At first he added the first full support for the Super Game Boy (one emulator emulating the SNES and GB at once. Though last I tried it the GB core was still a work in progress, particularly sound. This allowed things like the SNES mode in the US/EU GB Space Invaders.) Then when cracking the ST018 expansion chip, it was discovered to have an ARM-based CPU, so with the help of a GBA hacker he added GBA support. He was also took the next logical step and and began work on DS emulation but dropped it once he realized the DS was too different to continue supporting it. Not sure how the NES got added in.

byuu was working on Far East of Eden Zero, so he renamed his emulator after the main character of that game. Maybe he had other reasons, though, I can't remember.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: helaku on October 31, 2015, 04:47:44 am
About snes emulation I see that nobody talks about SNESGT.
From what I've heard it's better than Snes9X in terms of accuracy.
Here is a link: http://gigo.retrogames.com/download.html
Please tell me your opinions :)

P.S.  last stable build is 0.218 and last test build is 0.230 beta7
P.S. 2 I would like to see in the future a technical side by side test for Snes9X and SNESGT, which is better and why
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: MeganGrass on October 31, 2015, 09:27:45 am
My guess is the name bsnes was changed when the emulator became a multi-system emulator and the name no longer seemed appropriate.
At first he added the first full support for the Super Game Boy (one emulator emulating the SNES and GB at once. Though last I tried it the GB core was still a work in progress, particularly sound. This allowed things like the SNES mode in the US/EU GB Space Invaders.) Then when cracking the ST018 expansion chip, it was discovered to have an ARM-based CPU, so with the help of a GBA hacker he added GBA support. He was also took the next logical step and and began work on DS emulation but dropped it once he realized the DS was too different to continue supporting it. Not sure how the NES got added in.

byuu was working on Far East of Eden Zero, so he renamed his emulator after the main character of that game. Maybe he had other reasons, though, I can't remember.

Ah, that makes sense. I wouldn't completely disregard an emulator because of the name given to it, however, I do disregard bloatware. I wouldn't download and use a file compression utility that doubles as an internet chat messenger. That is an outrageous example, but the same principal applies.

Too much is too much.

I wouldn't recommend Higan for casual users to use.  I'd recommend SNES9X instead.  Higan is made exclusively for accuracy-enthusiasts who have the hardware and technical know-how to deal with the quirks of using it and configuring everything properly.  They also have to be willing to not bother sending suggestions to byuu and stick purely with noting bug reports if they want to contribute to development (or fork the code if they can do programming).

People can complain about Higan but it is under GPL so just fork it and stick it up on GitHub and change the stupid UI/folder system to something better.  Perhaps use the 'Performance' core by default and integrate all 3 cores as a menu option instead of seperate executables.

Good point.

It just gives me peace of mind in knowing that the author put real care and thought into development, as opposed to those who've attempted the same for the sole purpose of bragging rights. It's nice knowing that when I boot a game with Higan it will work as the original developers intended, and that's something that other emulators can't guarantee.

I do recommend Higan for ROM hackers, though. All too often, people have designed hacks using something like ZSNES as a base for testing, without even putting any thought towards whether it will work on real hardware. On the emulation side of things, Higan is as close as one can get to that. I will respect a hack that works on real hardware much better than one that doesn't, no matter the grand scheme of said hack.

...and I can write c/c++ programming language just fine and have a pretty decent understanding of video game programming and such, I just don't feel the need to take it that far.

The thing with byuu is they always march to the beat of their own drummer.  That's just how it goes; their emulator their rules in a way.  Not that I agree with it but that is how they decided to do it.  They never made Higan for the community; it was always a personal passion project.  I find it ironic that byuu expects the wider emulation community to adopt Higan as a standard when he's so openly hostile to anyone that doesn't agree with them.

I totally understand the passion project aspect, I have a few of those myself. When it comes to presenting my results to the public, I can also handle constructive criticism, though... and that's where I begin to lose respect -- byuu doesn't even begin to consider that what he's done with the file/folder thing is just flat-out absurd, especially when he expects everyone to accept it.

Sometimes, the concept just isn't acceptable. It sounds good in theory, but is absolutely horrid in standard practice. It sucks to let go of these kinds of ideas, I've had to do it myself, but if one expects everyone at large to adopt, exceptions have to be made -- not the other way around in the case of the folder/file ordeal. There are much better ways to handle the situation and telling everyone to piss off most definitely isn't the right way to go about it when you're trying to get everyone to love you.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: obscurumlux01 on October 31, 2015, 05:56:29 pm
About snes emulation I see that nobody talks about SNESGT.
From what I've heard it's better than Snes9X in terms of accuracy.

What you've heard may or may not be accurate and 'hearsay' is rarely suitable for making a point.  However, I do get the gist of how you feel in your opinion that it may have better accuracy based on your own personal experiences with it.  I'd love some game-specific examples (like how byuu mentions that Speedy Gonzales game, the shadow from Air Strike Patrol, Timecop, and dozens of other bits in various games).

The reasons I will not consider using SNESGT right now are simple:

1 - Not open-source?  No thank you.  Nearly every piece of software I use (other than Windows itself & hardware drivers) is open-source on this gaming PC of mine.  I have a laptop that is 100% FLOSS with Ubuntu MATE on it primarily for banking & taxes & economic/sensitive transactions & work-related stuff.

2 - The 'terms of use' they have are outright absurd since GPL'd code doesn't have any such restrictions on where or how it can be used and LESS restrictions on redistribution and commercial use.  The 'terms of use' at the BOTTOM of the page (so you can easily miss/ignore them) are also in Japanese-only because 'fuck you non-Japanese people'.  The plugins were provided for other languages yet they couldn't ask the translator to also translate the terms of use on that website?  Yeah right :P

Spoiler:
Pardon the Google Translate quality of this.
Quote
Please observe the following terms when used.
For software and other all that is here, if you make the download and run,
and you will have accepted the following terms unconditionally.
Prior to always run, please take a backup of your environment to perform the execution.
Please do not run on a commercial personal computer.
Please go at your own risk if you want to run.
 Absolutely on our side is not responsible for any damage or the like.
Basically reprint is free, but please go on you observe the following conditions.
Please contact because it does not matter post.
When you reprint, please do not modify the archive and run files, and the like.
Due to the nature of software, reprint to non-network magazines and books, etc. I have refused. Please be understanding.

So they're basically prohibiting that you run it on a 'commercial' PC which isn't clearly defined.  But if I get a 'business class' PC that is more expensive with better hardware, better warranty, and better support but use it at home then does that count?  Apparently it does under their definition.  Perhaps it is a translation issue and they meant 'commercial use' or 'for profit use' instead.  I'm gonna give them the benefit and presume they meant they are prohibiting commercial use.

Thing about GPL software is that not only can it be used unrestricted for commercial purposes but the license explicitly allows you to do so.  The only drawback is that if you modify the source code for your own use then you are required to provide a clear and accessible download to the modified source code to the general public without the need to explicitly ask permission for it first.  Nintendo sticks PARTS of the source code files on their Nintendo Japan website despite using English source code from English websites.  I haven't found any mention of the source code on the Nintendo of America website.  And unless you know Japanese you won't find it on the Nintendo of Japan website.  This is clearly a deliberate 'obfustication' attempt to make the source code release as difficult to find as possible.

They want to be contacted before you repost it anywhere (what!?) unless again the translation is wrong.  Since they don't seem to know English then what is the point of contacting them in the first place?  I don't get all the people saying 'do not modify the archive' when they could be far more explicit in saying 'do not alter the original files within the archive'.  But meh, it is their software code so w/e.

I'd much rather use open-source and GPL software because it respects my freedoms rather than chaining me to arbitrary and bass-ackwards decisions that will come back to bite them in the ass.

You want me to use closed-source software from someone that I don't know who doesn't speak or know English and doesn't give a shit about providing Terms of Use in English?  Are you serious?  Then on top of that you want me to use software that hasn't even hit a stable v1.0 yet and may be abandoned at any time with little to no way to contact the author and communicate with them if I don't know Japanese!?  Yeah no thanks.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: Rodimus Primal on November 01, 2015, 12:18:58 am
I think the last time I tried setting up SNESGT to try it out I got my virus protections going crazy. If the terms of use are in any way a telling sign, then I'm not even going to touch that one again.

I just downloaded Higan v095. I can say the GUI is improved, slightly. I can set hotkeys as I need, and I can tell it WHERE the library folder is. But then comes the issue with that. Icarus, which should NOT be a seperate program, converts the ROMs I import where the DEFAULT folder is for Higan, not where Higan's setting are. I NEVER leave stuff in the My Documents folder and that's where Icarus places the Library. Higan didn't know where to look until I copied the files. To the average user, that is so tedious and unneeded that I'm glad I only let it copy a couple ROMS for testing.

Then comes the video issue I have with Higan that I think I mentioned before. In full screen the game doesn't fill the 4:3 space (I don't stretch my screen like some do) It's rather annoying to play a game in a smaller space than other emulators allow. With that all of my trials of Higan have left me looking at the emulator only for testing purposes ONLY since it's as close to actual hardware as you can get in terms of PC emulators. I'm sticking to SNES9x. I still recommend that over any other SNES emulator and plead with people to leave ZSNES like people have done with Nesticle.

I haven't given up on puNES though. I have had no issues with Nestopia but I'd rather have a great working modern NES emulator that is still updated so that there isn't any compatibility issue with PC operating systems.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: helaku on November 01, 2015, 12:00:22 pm
Good points obscurumlux01
To tell you the truth I don't use SNESGT very much, i've used it only a few times. My favorite emulator remains Snes9X.
So, about what you've said "However, I do get the gist of how you feel in your opinion that it may have better accuracy based on your own personal experiences with it" it's not correct. I didn't say it have better accuracy I only said what I've heard/read on some forums that SNESGT is better than Snes9X (I've talk about stable builds not test/wip/dev/git etc builds) which is correct or not based on their statements/tests.
In the future I would like to see some test on SNESGT about the accuracy for the sake of studying ;D

Thanks!

P.S. I've done some quick tests using this page as reference http://floating.muncher.se/byuu/accuracy/ and here are the results for SNESGT emulation:
- Air Strike Patrol - fail (no shadow);
- Battle Blaze - fail (title screen);
- F-1 Grand Prix - pass (in game HUD);
- Harukanaru Augusta 3 - Master's New - pass (in game);
- Mecarobot Golf - pass (lesson screen);
- Moryo Senki Madara 2 - pass (reading text);
- SD Gundam G-Next - pass (scenario select);
- SNES Test Program - fail (burn-in test fail at APU section with error 16);
- Tetris Attack - pass (VS screen);
- Timecop - pass (distortion ship effect).
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: obscurumlux01 on November 01, 2015, 12:48:34 pm
Just did some quick checks.
SNESGT seems to check out clean from VirusTotal (https://www.virustotal.com/en/file/a87df773e029d10b1889de004a6cda390e37cc522cb5fc12f4e1b82ad9675623/analysis/1446399066/).  That is pretty impressive, even by the standards of most of those vendors.

I actually use GNSF from that same website (though I got it from Zophars Domain) and it seems to work well without issues and no detected malware from VirusTotal (https://www.virustotal.com/en/file/95bc07d79a865307018573e05571aba5070e741bde18fae5dbb8445bf4fbc9f8/analysis/1446399083/).

I'm still not going to use SNESGT personally but it may be interesting to test things out with it compared to SNES9X and Higan.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: FallenAngel2387 on November 01, 2015, 04:03:35 pm
Well, now the only issue I have with Fusion is finding an emulator that doesn't screw with the graphics in Comix Zone. It never had graphic issues on the console.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: helaku on November 02, 2015, 02:21:33 am
Some new info: http://wiki.libretro.com/index.php?title=Nintendo_SNES_Core_Compatibility
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: obscurumlux01 on November 02, 2015, 07:29:37 pm
Well, now the only issue I have with Fusion is finding an emulator that doesn't screw with the graphics in Comix Zone. It never had graphic issues on the console.

It has been so long since I played it that I never really looked at it in Kega.  You're right.  The shadows are all screwy for some reason.  What a shame.
Found several playthroughs but they all have the same obvious emulator bug.  Apparently even the Retron5 console (https://www.youtube.com/watch?v=pLR0qSgrVAI) (presumably with an original cartridge) has this issue!

Ok this is wierd.  Apparently this guy shows (on camera) plugging in the original cartridge into the original console and recording it.  Same shadow lines (https://www.youtube.com/watch?v=9Ul1aoAtLbE).  Maybe we're misremembering things!?  >_>

Need to confirm with someone else checking it on original hardware.  It has been so long since I've played this game on original hardware that I can't easily recall it with any degree of accuracy.  If someone wants to give it a whirl then I'd love to hear & see the results!

On the plus side I saw this beta version video on YouTube :) (https://www.youtube.com/watch?v=llMt1LN-di8)
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: Lilinda on November 02, 2015, 08:04:10 pm
There's a few possibilities.

1. The shadows are glitched on every properly emulated, well, emulator, and on at least one hardware revision due to a bug in the game's code. This would mean emulators that show unglitched shadows are either doing it wrong, or emulating slightly different variations. Recall that the console had two major revisions in the U.S., a kazillion versions where it was either an add-on or embedded into something, and who knows how many minor revisions.

2. Somehow all the emulators are getting it wrong, and something just happened to be wrong with that particular console/cart setup in the linked video.

3. The shadows are glitched in one revision of the game, but not in others. I don't know if the game has any alt versions outside of country/region differences, or any undumped versions.

4. Something else I haven't thought of. :P
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: FallenAngel2387 on November 02, 2015, 11:47:14 pm
That's just vertical dithering. Anything that shows graphics at their sharpest(like modern TV's, or emulators without a blur filter) will show that. It's like how awful Eternal Champions looks like, but it looked fine on the console connected to a CRT back in the day. Real quick in Fusion, select either TV Mode option(CVBS tends to be more readable with text), and you'll see it how you remember it.

The graphics issue I was talking about is that some objects will just glitch out, and the game won't look like it should.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: MegaManJuno on November 03, 2015, 09:06:04 am
Yep, the vertical lines in the Comix Zone shadows are a "trick" they used in conjunction with CRT TVs. Due to the way CRTs functioned, these created a fake translucency. The same can be seen with the waterfalls in Sonic.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: obscurumlux01 on November 03, 2015, 04:37:23 pm
That's just vertical dithering. Anything that shows graphics at their sharpest(like modern TV's, or emulators without a blur filter) will show that. It's like how awful Eternal Champions looks like, but it looked fine on the console connected to a CRT back in the day. Real quick in Fusion, select either TV Mode option(CVBS tends to be more readable with text), and you'll see it how you remember it.

The graphics issue I was talking about is that some objects will just glitch out, and the game won't look like it should.

1 - YOU ARE AMAZING!  I just did as you ask and it worked!  And yeah CVBS mode in Kega Fusion makes the shadows look like how I remember them as well as keeping the text more readable.

2 - I'd need to see screenshots of what you are talking about.  Aka what it looks like in Kega Fusion and what it SHOULD look like.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: FallenAngel2387 on November 03, 2015, 09:02:35 pm
I notice a lot of it happens when Alissa is chiming in, her graphic in the upper left glitches at times, especially when fighting enemies. The panel in the 2nd stage/page(whatever it is), where the Flying Creatures(literally what the manual calls them) come out of a hole, and you need to move a boulder on top of it, while there are 3 stacked on top of each other to the left that you have to eventually destroy. The whole panel glitches as your fighting the Flying Creatures, while those 3 boulders are in view. Things like that. Nothing game breaking, but it can be distracting, and  I never saw that kind of glitching in the game until emulation.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: helaku on November 04, 2015, 02:30:41 am
This bug only occurs in the latest build of Kega Fusion?
What I understand is that 3.64 build was released in a hurry and was not tested like 3.63.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: Lilinda on November 06, 2015, 01:02:16 pm
Yep, the vertical lines in the Comix Zone shadows are a "trick" they used in conjunction with CRT TVs. Due to the way CRTs functioned, these created a fake translucency. The same can be seen with the waterfalls in Sonic.

So, it was, in fact, option 4.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: FAST6191 on November 16, 2015, 06:09:15 pm
Not sure if it wanted to go here, the thread that provided the basis for some of this or its own thread but I will live with the results.
It was linked earlier today and some might be interested to read http://trixter.oldskool.org/2015/04/07/8088-mph-we-break-all-your-emulators/
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: helaku on November 19, 2015, 06:00:58 am
For Comix Zone did you try this emulator: http://aamirm.hacking-cult.org/www/regen.html
From the author emulator page: Regen is an accuracy focused emulator which can emulate the following Sega console and computer systems with very high degree of accuracy.

I notice a lot of it happens when Alissa is chiming in, her graphic in the upper left glitches at times, especially when fighting enemies. The panel in the 2nd stage/page(whatever it is), where the Flying Creatures(literally what the manual calls them) come out of a hole, and you need to move a boulder on top of it, while there are 3 stacked on top of each other to the left that you have to eventually destroy. The whole panel glitches as your fighting the Flying Creatures, while those 3 boulders are in view. Things like that. Nothing game breaking, but it can be distracting, and  I never saw that kind of glitching in the game until emulation.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: FallenAngel2387 on November 23, 2015, 10:15:51 am
Yeah, I've thought about another emulator, it's just kind of tough when you're used to one that can do 5+ consoles(it handles their really early Japanese exclusive consoles as well, like the SC-1000)/handhelds extremely well as is.
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: helaku on November 23, 2015, 03:07:50 pm
I\m very curious, did you try it to see if the bug still exist?

Thanks!
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: sics on December 15, 2015, 10:23:59 am
Hi I want to tell that until recently in China was developing a special version of Nestopia, this not only is more compatible than the original, but runs games he had never been able to emulate the popular emulators, so I thought interesting to share with who is interested.  :thumbsup:

(http://nestopia.gamemw.com/images/sampledata/R179-2.png)
(http://orig11.deviantart.net/7ff5/f/2015/320/d/6/dg_by_terwilf-d9gy6c3.png) Nestopia+Plus!+1.4.0.9+R230 (http://gadam.wodemo.com/file/359774)

     Official website (I think) (http://nestopia.gamemw.com/index.php/26-nestopia-plus-1-4-0-9-r230)
Title: Re: Emu Accuracy analysis: FCEUX vs. NEStopia
Post by: Smart89 on December 27, 2015, 11:02:28 pm
Hi I want to tell that until recently in China was developing a special version of Nestopia, this not only is more compatible than the original, but runs games he had never been able to emulate the popular emulators, so I thought interesting to share with who is interested.  :thumbsup:

(http://nestopia.gamemw.com/images/sampledata/R179-2.png)
(http://orig11.deviantart.net/7ff5/f/2015/320/d/6/dg_by_terwilf-d9gy6c3.png) Nestopia+Plus!+1.4.0.9+R230 (http://gadam.wodemo.com/file/359774)

     Official website (I think) (http://nestopia.gamemw.com/index.php/26-nestopia-plus-1-4-0-9-r230)

looks promising, like a mix between normal nestopia (filters and gui) and fceux (with compatibility with unofficial roms)  :thumbsup: