So, your account gets disabled here when you don't post frequently enough?
These emulators are receiving more and more criticism, when the authors have usually made a highly pragmatic decision to emphasize playing the games at fullspeed on lower spec systems over telling the user base to buy or wait for a faster computer.
This goes both ways. I see constant insults to my emulator because it's so unbearably slow (though in fairness, it really is.) And the majority of people favor playability over accuracy, so really -- the speed-oriented emulators aren't taking nearly as much flack as the accuracy-oriented ones are. It's only recently that they have begun taking any flack at all, in fact.
This kind of backs accuracy-oriented emulator authors against a wall, you can't justify your approach without insulting the speed-oriented emulators in the process by pointing out where your approach is superior, such as pointing to known bug lists or game-specific hack lists. It doesn't matter how much tact you try and use.
In fact, I really have more respect for people who put a lot of effort into optimizing their emulators, because this is really much harder than just implementing something that works, especially if extensive documentation is available.
From my experience, I'll have to
strongly disagree with you here. Some speed optimizations are tough, but a lot are obvious from a basic understanding of the system. Range testing IRQs, dynarecs, idle loop skipping, averaging cycle counts, synchronizing less frequently between components, etc are all standard fare and offer tremendous speedups. And adding game-specific patches to fix broken games is even easier, albeit time consuming.
It's only when you
really start trying to eke out every last ounce of performance that things really get tough. An N64 emulator on the PSP for instance, would be real pain indeed.
Whereas, when you're aiming for perfection, you already have an impossible goal in front of you. It doesn't matter how good your documentation is -- getting every last edge case working perfectly requires arduous testing.
To me, I have the most respect for someone who can make an emulator that requires at least a ~20GHz processor to achieve full speed. Not even I am willing to work on an emulator I know I'll never actually get to use for gaming. I limit my accuracy to that which can run on (my) current top-of-the-line modern hardware. But I don't see much point in catering to ten year old systems. There are already emulators out there for those. Whereas the original hardware won't be around forever for us to run tests on. When the last unit fails, we have to hope we've gotten it right, because we'll never get it any better.
What's the point of having a mentality of preserving an experience for people when you have no consideration for giving people that experience today? ... I don't see what's so morally superior in this.
Agreed and agreed.
I was regrettably too dogmatic when I first started off, and sadly I cannot change the past, but I calmed down after a while. The good news is, as I said above, we
already have emulators playable on modern hardware for most systems, N64 included, so nothing is being lost by pursuing more faithful emulation now.
However, no approach is truly superior to another. They're all different means to reach the same end goal -- 100% compatibility. They just have different tradeoffs in the process. It is beyond tasteless to insult another emulator, regardless of the method they have chosen.
Especially when you aren't paying a dime for it.
But, leave it to human nature to proselytize every last possible line of thought in the world, much to the chagrin of everyone else.
You then have some developers of mame/mess (of which mooglyguy is barely one, I'm not really talking about him) talking about how accurate MAME is when there are lots of other emulators which completely smoke it in regards to accuracy.
Do you have any cases where they've done this and it wasn't justified? I've yet to see them claim superiority to NES, SNES or Gameboy emulation, for instance.
Yes, I suppose byuu, author of bsnes, calls this approach a "state machine".
State machine is actually a very generic term. It's C analogue would be:
switch(state++) { case MAX+1: case 1: ... break; case 2: ... break; ... }
To the extent that you need a way to enter and exit in the middle of performing a specific CPU function, so that you can guarantee calling CPU::run() won't execute > ~100 cycles and desync your RSP, yes. That would require a state machine in a single-threaded environment. It's basically a software method of saving the program counter position, so that you can leave a routine and then re-enter it later on.
