donluca wrote:
The problem with MiSTer, just like other emus, is that it will always be as good as the coder makes it.
People think that in order to obtain perfect accuracy, each game needs to be tested because they might show issues. This is wrong in so many ways I honestly don't even know where to start.
Good start. All true.
donluca wrote:
Speaking of emulators and, more specifically, about platforms which have been around for decades and had all their chips decapped and studied at transistor level, if you make an emulator which runs fine for some games and has bugs/issues with others, you have messed it up.
Every single emulator (including all FPGA based emulators) use hacks. So, everyone has messed it up? That's extreme.
First of all, absolutely no video game system has been completely researched and photographed at a transistor level. AFAIK, the 6502 processor is the oniy component that has been (more or less) completely documented. That means dissolving the chip and photographing it layer by layer. The research hasn't been done.
Also, there aren't any affordable and conveniently sized options to completely implement a system on a true transistor level.
We don't have the hardware to do it. We don't have the documentation.
donluca wrote:
That's it.
It's not that "the game does strange things" or "was coded in an unusual way", it's because your understanding of how certain hardware works is lacking and/or you haven't coded it properly.
Sure, but I don't have the information or hardware to do it "properly" right now.
donluca wrote:
What happens in 99,99999999999999999999999999999% of the cases where someone finds a bug in a certain game, the coder just adds a handler to have that game working correctly, better known as a patch.
And, again, this is so wrong that I can't really find any words to justify such approach.
As hardware gets more powerful, we have the ability to emulate more accurately and "organically" derive proper behavior. In the meantime, everyone is using hacks.
donluca wrote:
If a game has a bug in your emulator, you don't make a patch, you get back to the drawing board and try to figure out what's wrong in your understanding of the hardware or the code you've written, because a game which runs flawlessly on original hardware MUST run in the exact same way on your emulator if you've done your work properly.
This is what happened with lots of emulators in the past: they became a jangled mess made of patches upon patches and it's no surprise their source code was never released, because you would have witnessed the worst kind of spaghetti code you've ever seen in your life (been there, done that, I preferred to start anew, from scratch).
Is that what happend? Or was it because we wanted something playable that hit frame rate on our hardware at the time?
So sick of spoiled children pissing on all the hard work emu devs poured in. You're not special, kids. You have better hardware available. You're not magic.
donluca wrote:
I really hope that all the people working on MiSTer cores are doing things properly and the bugs in the SNES code reported will lead the core's author investigating about what's wrong and not just make a patch to have those games working properly and call it a day.
Good thing everything is on Github so we can check ourselves what's been done (and how).
I already have the money ready for a MiSTer board and accessories (I/O, RAM, etc.) but I'll wait until the cores' code has reached a certain maturity.
And, just to make sure: this is not an attack to all the awesome people investing their time into making cores for the MiSTer, but rather a glimpse into what happened in the past to make sure such errors won't be repeated and, hopefully, to let us enjoy proper, cycle accurate emulation.
The people working on MISTer are doing the best they can with what they have available to them.
Also, cycle accurate is a reference to timing, not proper hardware behavior.