The "110% accuracy is the only true master race" argument is just as childish as the translation vs localization argument was in older days of translation hacking. People put different values on different aspects of emulation. Get over other people having different opinions.
I've never faulted anyone for their opinions. I've merely been stating my own. I feel like I'm the lone emudev voice in a room full of ROM hackers. Clearly I'm in the minority in this circle.
What I will say is that we can look at history to see how emulation progresses. Very roughly, there are two stages.
Stage 1 is where emus are hacked together to "just get the games working". This is the goal of first/second-gen emulators for pretty much any system. We saw it with NESticle, we saw it with ZSNES.
Stage 2 is "okay we got games mostly working, but they're not perfect, so let's focus of emulating the hardware more faithfully to improve accuracy". We saw it with NEStopia/Nintendulator. We saw it with Higan.
This is how emulation has progressed historically... and how it continues to progress.
You seem to be content with stopping after Stage 1. "What do I care whether or not the emu is accurate? As long as it plays the games, isn't that the only thing that matters?"
Which is a totally legit opinion. And in a way, you're sort of right. What does
it matter how accurate an emu is as long as it lets you play games and make hacks?
But again... like I tried to say in that other thread... that simply is not how emulation works. History has shown that emulation progresses to stage 2 whether ROM hackers want it to or not. Emu devs simply have a different mindset -- and ultimatley emu devs are the ones who are making the emulators, so they're the ones who get to dictate how emulation progresses.
More questions from obscurumlux01 via PM:
I'm curious why you dislike the MSU-1 but I get it. Your ideals are that of 'purist' thought. You want to do only what was released on the console itself at the time and what is capable on the console without special custom chips that are created later.
I suppose you could say that... but I wouldn't say I refuse to emulate new hardware -- it's just not a high priority for me.
What about pirate carts?
Like I said before, if there's hardware, I'll try to emulate it. Though pirate mappers and indie cartridges like SD2SNES are definitely going to be lower on my list of priorities than commercial hardware.
I get that SNES emulation is different from NES emulation, but on NES there were 'extra mappers' forked from the regular FCE emulation project and later merged back into the current FCEUX project. So the question in my case is that wouldn't it be prudent to support these extra mappers for the purposes of pirate carts and homebrew?
NES and SNES are not as different as you might think when it comes to cartridge emulation. The biggest difference is that the NES emudev scene is much more organized in how it categorizes cartridge hardware.
On the NES you have to emulate 80+ different cartridge layouts.
But you also have to do the same on the SNES.
MMCs and other additional hardware are certainly more common on the NES -- but the hardware on SNES cartridges is far more complex. There is nothing that comes even close
to the complexity of SuperFX on any NES cartridge.
That said... I'm not entirely sure what 'extra mappers' you're referring to. Are you talking about the FFE mappers? Because there is little to no reason for emulators to support those. They've effectively been deprecated by the NES emu community.
According to byuu, the ExLoROM and ExHiROM are just a series of ~80 or so mappers (including mirroring variations) that just tell the emulator where to find the data whereas on official hardware there are no such mappers as far as hardware is concerned and it would just read it regardless of anything else.
My understand of the terms:
"MMC" = additional chip on the cartridge which provides logic for controlling/swapping blocks of memory. I tend to lump things like SuperFX in this even though it technically isn't an MMC, but it is an additional chip which provides logic.
"mapper" = a combintation of the MMC(s) on a cartridge, as well as the pin layout and address mapping. Basically the "mapper" is the description of how the cartridge as a whole operates.
LoROM and HiROM don't require any MMCs, they just connect address lines to the ROM chip in different ways. But they're 2 different "mappers" because they describe two different cartridge layouts.
What byuu was talking about was that LoROM and HiROM are over-generalizations, and that actually there are ~80 different cartridge layouts all with subtle differences in how they're arranged. Some of them resemble
LoROM or HiROM, but are a tiny bit different. And in fact, if you emulate the SNES using only LoROM and HiROM as your only 2 mappers, you will quickly run into several games that fail -- like Megaman X, the DKC series, etc.
Many cartridges intentionally went with slightly weird mappers to discourage piracy and prevent games from playing properly on copiers. It's actually not unlike what puzzledude did -- the difference is they actually produced hardware.
If something is POSSIBLE to get working on official SNES hardware without extra custom chips (like MSU-1) and it involves supporting new mappers then wouldn't that be worthwhile to pursue?
Again... show me the hardware, and I'll try to emulate it.
But I'm not going to go out of my way to emulate things that are nothing more than the brainchild of a ROM hacker who doesn't want to conform.