nesdev.org

He means you could have the most technically proficient, user friendly emulator ever and people probably still wouldn't use it over any of the ones you're disappointed with.

WedNESday wrote:Byuu I'm not beating on your emulator.

Well that's a relief.

To me the bit about technical merit means that people use an emulator that is familiar to them. Emulators for an already emulated target have a chance to become familiar only on a new host platform, such as when the underlying operating system breaks the previous familiar emulator. And for the combination of Win32 host and NES target, that's Nestopia. Perhaps other ways to give new emulators a chance may include

• Making new homebrew releases subtly incompatible with old emulators, such as a new multicart-oriented mapper that turns out to be a great MMC1 alternative in general
• Making a common API to allow new emulator cores to be plugged into an existing front end or for new front ends to be written around an existing core
• Research into effective input methods for multitouch devices

Kasumi wrote:He means you could have the most technically proficient, user friendly emulator ever and people probably still wouldn't use it over any of the ones you're disappointed with.

Well then he is very wrong.

WedNESday wrote: What exactly do you mean by technical merit means nothing?

He means that you and I are screwed no matter what technical innovation we might bring to the emulation scene because there's no...life changing event...that could possibly occur that would suddenly make our emulators better than the rest.

I've been living that reality for years but yet I plod on...people tell me all the time my emulator's no good.

Tell me which emulator is yours so that i can say something nasty about it test it.

Edit: *Spots the word 'NESICIDE' in the above post*

I use NESICIDE extensively for source level debugging when I need to single-step my code. But I usually try to do it as a last resort because it's just so frustratingly slow on my netbook.

So personally I'd love it if NESICIDE's emulator could be optimized a bit more. But I realize me and my cheap netbook might not be the main target audience and I appreciate NESICIDE for what it does provide me with when I have to track down bugs. And when time comes to upgrade my hardware again it'll probably run at decent speed anyway...

Of course BSNES doesn't get very popular for how good it is. It was a SNES emulator that won't even run a majority of SNES ROM's for absolutely no reason except for he dislikes SMC ROM's. You dislike SMC ROM's, people (Like me and many many others) dislike emus that you have to jump through 10 hoops to run them. Why would I use it then? Nobody will.

WedNESday wrote:

Kasumi wrote:He means you could have the most technically proficient, user friendly emulator ever and people probably still wouldn't use it over any of the ones you're disappointed with.

Well then he is very wrong.

Release WedNESday and prove him wrong.

I dunno, when I was looking for an emulator to use, I tried a bunch. Nestopia was the one that gave me the best initial experience, especially because it has a smooth proper vsync in fullscreen. I also like its APU mixer. As far as emulation accuracy, it hasn't yet failed me on any games I wanted to play, so it's my emulator of choice for playing.

For debugging, I really like FCEUX's debugger. It took me a while to figure out, but once I had gotten my head around it, I've found it quite well featured. (I also rewrote the debugger documentation, to be hopefully easier to follow for others in the future.) It has become my debugger of choice when doing NES dev stuff. Like Nestopia, the accuracy of the emulation has not yet failed me where it counts. I also use FCEUX to make videos, since it has a very convenient AVI output.

For testing, I tend to occasionally test on a variety of emulators. Nintendulator is included since it has a reputation as the most accurate. I don't know the specifics of what it does accurately that FCEUX doesn't, but this has not yet turned out to be relevant to my dev work. I really just test with it for the sake of testing. Other than Nintendulator I keep a few other emulators around for testing, but in those cases it's more to expose problems due to inaccurate emulation (this has definitely been relevant to my dev work). I also like Nintendulator's OAM viewer, which FCEUX does not have, but I need to debug the OAM very rarely.

Anyhow, I use both Nestopia and FCEUX very regularly, but for different reasons.

WedNESday wrote:... Nestopia also had no fullscreen VSYNC.

rainwarrior wrote:Nestopia was the one that gave me the best initial experience, especially because it has a smooth proper vsync in fullscreen.

*chuckles* And this right here is exactly why the thread subject is a matter of opinion. Or it's just another case of a) badly-designed UIs (Vsync setting in Nestopia is under Options -> Timing, not Options -> Video, and at least on XP with an nVidia GTX 560Ti using 310.90 drivers it does control Vsync in both full-screen and windowed), b) graphics drivers and/or their "control applet" not doing what they're supposed to do, c) the operating system being an asshole (for example on Windows 7 -- where Vsync should work reliably -- I see occasional graphical stutter in most emulators, while in XP on the same hardware I see no such thing).

byuu wrote:tokumaru is the one that's upset. Better him than me.

I'm not upset. Not about emulators at least! =)

Maybe 10 people even use 30-bit display depths.

I'm not sure how many people use blargg's filters (I'm a big fan, whenever an NTSC filter is available I use it - even if just for fun on systems that didn't have composite output to begin with), but I imagine more than 10 people do. Not that it matters, I know, you made it clear that you wouldn't bother pleasing others anymore. I never questioned your decision, I actually kind of admired you because of it. You just happened to get rid of a feature that was important for me, so I didn't feel like using the emulator anymore.

I really don't care what you think about the split ROM format.

I know you don't, you made that very clear. To tell the truth, what it did to SNES ROMs wasn't even that bad. I don't have entire ROM sets available for playing (I do have some huge compressed sets backed up somewhere, though), so it's not like I have a million ROM files to manage, I just get the games I like when I feel like playing them. I haven't tried your NES emulator, but if the Application Data thing Dwedit mentioned is true, then that's gotta be pretty annoying.

Argue on technical merits, I can't have a debate with you on pejoratives.

Unfortunately, I don't have a better solution for storing/describing ROM images. To me, the ideal ROM format would include a complete representation of the hardware... basically a list of components and how they are wired. That way emulators wouldn't have to use mapper numbers, databases, detection hacks, or any of that crap, they'd just emulate the specified hardware. The emulator would interface with the emulated cartridge only through the signals present on a real cartridge connector, so that the console emulation wouldn't need to worry about mirroring/mapping or anything that happens on the other side. I imagine this is probably too computationally intensive to be feasible, but I'd like if emulation was like that one day.

Once the emulator loads it in, it's all the same.

The fact that you know this does make your refusal to parse a simple format as iNES look like a whim. There's no library bloat, no performance loss, not a single technical reason for rejecting that particular ROM format. You simply don't like it, and you have all the right keep it away from your own program, but you can't deny the stubbornness of this decision: you could satisfy many people with minimal effort (you already have the parsing implemented if you can import the ROMs) and not a single negative technical side effect, yet, you don't.

Distracting side tangents: compatibility with other flash carts / emulators. Important, but if backward compatibility were the milestone, we'd all be running MS-DOS still.

It's not my primary OS, but I certainly do have DOSBox installed. Because of this I am able to run the exact same games I did on my 386 without having to run them through some converter that will turn them into Windows programs, which are (arguably) better than DOS programs. I like that DOSBox will gladly accept my DOS game and present it to me like it was a Windows program.

Here are some interesting things that reasonable people can disagree upon: the format of the markup to explain boards (binary, plain-text, XML, BML, ...), whether to mark up boards at a high-level (uses VRC2 with the important two pins mapped to X and Y) or low-level (PRG A0-17 connects to 74LS139 pins 11-XX, 74LS pins connect to VRC2 pins YY-ZZ), whether to use an internal or an external database (or both), etc.

I'd love if ROM images where bundled with complete detailed descriptions of the hardware necessary to connect them to the console. But, like I said, this probably isn't feasible.

rainwarrior wrote:Nintendulator is included since it has a reputation as the most accurate. I don't know the specifics of what it does accurately that FCEUX doesn't

Nintendulator is much more committed to faithfully emulating the internal workings of the machine, while FCEUX is more high level. For example, FCEUX doesn't seem to emulate the whole sprite evaluation/fetching process, so if you're experimenting with bankswitching CHR during HBlank you won't get any useful results from it. Things might look correct, but in Nintendulator, Nestopia or the actual hardware you might have half of the sprites using a set of tiles and the other half using another.

It also seems that FCEUX doesn't show many types of mid-scanline PPU changes, so if you're trying to time scroll changes, palette changes, things like that, so that they happen during HBlank, you can't trust FCEUX. Most of these effects aren't very common in homebrews, so programs that stick to "the rules" (PPU updates only during VBlank, no raster effects) will hardly have trouble with FCEUX, but if you need try new PPU/APU tricks or adjust precise timings, FCEUX is a terrible choice.

@James Will do ASAP.

@koitsu Timing is a bit of a funny place to put VSYNC, maybe. I did check under video and didn't see it.

> And for the combination of Win32 host and NES target, that's Nestopia.

Exactly. You can try and go for Win64+NES, or if you want to bet on Microsoft not abandoning it in two years, Metro+NES.
Won't win you the contest today, but maybe in 10 years you'll end up on top for being the first, best, most polished choice when people start switching.

> Well then he is very wrong.

Well if I'm wrong, then why are you complaining in this thread? You said yourself your emulator was feature-filled.
Since you know more than me, tell us why your emulator isn't as popular as Nestopia.
But you'll see for yourself. It took me 15 years to learn this lesson. You'll learn it too eventually.

> people tell me all the time my emulator's no good

Don't do it for them. Do it because it makes you happy. If you are going for popularity, it's a path of misery and disappointment.

> 3gengames

Don't feed the troll.

> for example on Windows 7 -- where Vsync should work reliably -- I see occasional graphical stutter in most emulators, while in XP on the same hardware I see no such thing

Microsoft really screwed the pooch on DWM.

Apple did it right: it gives your OpenGL apps a "fake" Vsync right after the screen render has finished. That gives you almost an entire frame to get your data into the backbuffer.

On Windows and all Linux compositors I've tried, Direct3D and OpenGL still tell you the real monitor Vsync. So when the compositor is on, you fight it out with the compositor. Sometimes you blit right before the compositor blits to the monitor, sometimes the reverse happens. You get guaranteed choppy video.

> You just happened to get rid of a feature that was important for me, so I didn't feel like using the emulator anymore.

Yeah, I completely understand that. If it's any consolation, I'd love to have the NTSC filter back as well.

Actually, I'm looking for something lighter weight these days. I just want the blending effects, not the color degradation (eg simulate SCART-RGB only, no need to do the RF noise in my book.)

> but if the Application Data thing Dwedit mentioned is true, then that's gotta be pretty annoying.

Well, in the next release you can put the folders wherever you want, there's a setting added to the GUI for it.

Some of the systems I emulate allow you to write to the program ROM as well, because it's all flash. Like the BS-X Satellaview packs. So consider it just me storing the save RAM files. This way you keep your pristine ROM, and I can modify the copy as real hardware would.

> I imagine this is probably too computationally intensive to be feasible, but I'd like if emulation was like that one day.

I love that idea as well, but yeah I agree, too computationally intensive.

I thought about using 6502 as the intermediate language for the VM (since all NES emulators have 6502 cores anyway), but it's not going to be easy to write all the mappers that way, and nobody else would support it anyway, so why bother.

> The fact that you know this does make your refusal to parse a simple format as iNES look like a whim.

Only I do parse iNES. You can load iNES games with higan v092. And for koitsu, you can load ZIP files that contain SMC images with copier headers prepended onto them now too.

People are simply upset because I'm removing all the excess data, generating a board manifest (from an internal database with heuristics fallbacks), and putting the copy of the game itself in another folder. They don't want that copy made. But that's too bad.

> not a single technical reason for rejecting that particular ROM format

Did you completely miss where I mentioned VRC-n pinouts that iNES 1.0 can't describe? That's a technical reason right there.

And I even try and handle that case anyway. I choose what I guess to be the more popular games to have those work out of the box, eg I run Contra but not Ganbare Goemon.

> you already have the parsing implemented if you can import the ROMs

This is what people have a really hard time with. Importing == Playing. You can choose Load->Import every single time. Again and again. Your saves are kept intact.

The entire emulation core is built around the folder concept and requesting split pieces. It is too much work to make it support both split and merged files. So I split the files prior to playing, and I leave your original merged files alone.

You can pretend there is no game library, there are no game folders, and higan works exactly like every other emulator.

If the extra disk space (200MB for NES library, assuming you actually play every game ever made) is that big of a deal, then yes. I'm not going to please you. You can skip using the emulator, it's fine, I understand.

> I'd love if ROM images where bundled with complete detailed descriptions of the hardware necessary to connect them to the console. But, like I said, this probably isn't feasible.

Wide-scale, becoming the de-facto standard? No, it isn't possible.

Making a complete game set in your format, with all of this hardware descriptions included? Sure.

You could include Verilog simulations for the entire PCB if you wanted. Even if emulators don't actually use it, for posterity's sake you could include it.

This is the secret: don't worry about becoming the new #1 standard. Do what you think is right, and people who agree with you will thank you and work with you. To hell with the rest. 9:10 people hate my game folders, but 1:10 love them. And I love having those people on my forum, they're people I get along with. Much better than having a whole lot more people who disagree with me on my board.

My only real mistake is responding to these kinds of threads. It's mostly a waste of time. It's just ... my tacit acknowledgement that I know I'm not always right and don't always do things the best way possible. I really do want constructive, positive feedback. By doing things differently, I've already shown that I'm willing to change things. If there's a better way, and you can prove it to me, I'll switch to your way. Saying iNES 1.0 isn't going to work. I've already pointed out its shortcomings. Until they're addressed, you haven't solved anything. iNES 2.0 is a lot better. I can't wait until I actually encounter an iNES 2.0 ROM in the wild, I'd love to parse that format as well.