Quote:
If you are only interested in running existing games perfectly and passing all existing tests, it seems like you don't care about making the emulator actually accurate, you just want a certificate saying it is so.
Once again I'm pleasantly surprised to hear that here. I got into an argument with someone recently over this exact thing.
Quote:
Not really, but what's the problem if YES? Are you against the use of test ROMs somehow? Unfortunately, I'm unable to build a dev-kit for reasons I won't discuss here.
Game compatibility and test ROMs are not appropriate tools to enhance the state of accuracy for an emulator. Let me give you an example:
A while back I found a weird glitch that was throwing off the timing and breaking a certain golf game. On my testing branch, I was able to fix the glitch very quickly by changing what I assumed to be the problem. But of course, to commit that I wanted to verify on hardware. Sure enough, I was wrong. That wasn't what real hardware was doing. I had to try about 20 more things, ruling out every possibility, before I found out what was really wrong and got it fixed properly. It's very often the case that hardware is doing the last thing you'd expect. The most illogical one of all.
For an analogy, say your emulator is a square and you want to fit it into a circle peg, only you can't see the circle at all without a dev-kit. You can chisel away and keep trying, but by the time it finally passes through, you won't have anything at all like a circle. You could just have a small square, for instance.
You can't be certain that what you've done to pass a test or get a game working was the correct answer, and neither can anyone else looking at your work. Development of an emulator that doesn't target those hardware restrictions and limitations creates a tiny square that is much
more forgiving than the real thing. You'll see this often in emulators: it's why homebrew fails while commercial software works so well. They're working from the top down rather than from the bottom up.
Of course, not everyone has the ability to obtain a dev-kit and that shouldn't be held against you. I'd say at the very least, please aim to be as restrictive as possible. For instance, if you're not sure if you can write to a certain register at a certain time; don't allow it at all. It's better to find out you broke a game that relied on that behavior than for a homebrew dev to find out that your allowing it broke their code on the real system.
Quote:
The UI is the least important thing though, IMO.
For a developer or program tester, this is absolutely true. But the average user will run screaming if they don't like your UI. There does actually seem to be a good subset of users who really love completely custom UIs for their uniqueness over their function. You can see that with Genecyst, ZSNES and RetroCopy for instance.
It may not look pretty, but nothing beats platform integration for usability. Knowing that you can tab through controls, copy and paste text out of the debugger, that drag and drop works, that all the keyboard shortcuts follow the convention of your OS, that you can use the title bar to move and window borders to resize the window, etc. It's a much smaller learning curve.
Quote:
If I would be harsh, I could say for example that all emulators are not accurate since they don't support the same behavior of real mappers when the game fail to initialize it properly.
I really don't think any emulator is even close to my ideal of accuracy, including my own. I was quite surprised to hear how black box the NES PPU still is, even though you guys have pixel-level renderers now.
Initialization is the worst: often times it's random, but randomness is an emulator breaks testing, breaks movie playback, breaks netplay, etc etc.