The analogy would be that a lower level emulator can be less accurate than a higher level one if it's poorly or incorrectly done. My argument is that in many cases a higher level of emulation can receive the same degree of accuracy as a lower level of one.
My point exactly. "If poorly or incorrectly done."
With the SNES, we know the exact levels of precision needed to ensure that input and output always match.
S-CPU = ~10.5MHz
S-PPU = ~10.5MHz
S-SMP = ~1.024MHz
S-DSP = ~1.024MHz
Now you'll say, the S-CPU runs at ~21MHz, and the S-DSP at ~2.048MHz! Yes, but the CPU's minimum cycle length is 2, and the S-DSP always executes exactly two cycles before executing one S-SMP cycle. Anything less than this, and it's absolutely impossible to pass all edge cases. That's not theory.
Now if someone were to say, "no, you need to break the S-DSP down to 2.048MHz!", I'd probably scoff at that, too.
What you said is that the to get the DSP emulation "right" it must be done at the instruction level. I said that this is not necessarily true
It is for the S-DSP. You have to run it at 1.024MHz. Otherwise, games will fail. Koushien 2, for instance, writes to the echo data location register while echo writes are enabled. If you emulate it at the sample level, 32KHz, you'll end up writing echo data on top of program code and crashing the game.
If the games DO run fine then what other problem is there?
Basically, as you allude, perfectionism. Remember Puzzle Bobble or whatnot in MAME? They had simulated this logic chip or whatever, and it ended up causing very subtle changes in behavior of the game that nobody noticed.
I know that really doesn't matter to most. I know I'm neurotic about this. But you know, we have the knowledge, we have the ability, we have the technology ... why the hell not see what we can do? We already have speed-focused emulators. The alternative is to just stop trying because we already have all known games working. And that's lame :P
What about the newer reverse engineering results and documentation that are available to the new programmer? Faster computers placing less of an emphasis on speed? Better tools and compilers?
This is all available to existing emulator authors, too. They fall behind because they don't work as hard as the new guys. I'm tiring myself (though mostly from having nobody else to talk technical with). I hope someone surpasses me soon, too.
although I do think BSNES has helped fuel the demand for "more accuracy, at any cost."
I know, I pushed way too hard for way too long. As I said, shameful behavior. I learned a lot along the way, too. That decisions are not so clear cut, that there's no right way to do anything (just a lot of wrong ways.) The savestate issue, for instance. That was really tough. And splitting up a CPU to subcycle levels the normal way is absolutely
painful beyond any normal person's imagination.
Second of all, it's far from just HERE, it's emutalk, NESdev, ROMhacking.net, even ngemu. Did you notice that mudlord has echoed my sentiments? And some people are really, really hostile about it. I know you already saw MooglyTwo's flaming rant on emutalk about trash N64 emulators.
NESdev is a given. That's the whole point of that site ;)
I don't so much agree with the other sites, from what I've seen personally. But then you've seen other stuff. I suppose it's true that we see more of what bugs us than what does not.
And we both agree that it's not cool to attack another freeware emulator
for any reason.
But I'm forced to continue to disagree about the severity of people attacking speed-oriented emulators. I still think the tide is far from turned on that issue.
MooglyGuy -- in a lot of ways, he reminds me of the passion I had when I first started out. I think he'll calm down in time. But I shouldn't say too much, as I don't the guy at all. But both myself and him started off in scenes where accuracy was the absolute last thing on people's minds. When you're immediately backed against a wall, you tend to start swinging a lot faster.
In which case I'd ask you to clarify exactly what it is you consider the emu scene.
As you surmise, the casual users.
I've never once seen you get attacked for preferring accuracy, only praised, regularly.
I'm sorry that I don't keep thread post links handy (that'd honestly be a bit creepy). But I assure you this is not the case most of the time. Here and on RHDN? Yes, people are exceptionally nice to me. I'm extremely flattered by that. I also have a real presence on these sites to explain my actions.
My "spin" is that a lot of people these days don't even have a good understanding of what the accuracy they speak of IS but they demand it from emulators. I know you saw that OTHER thread about N64 emulation on emutalk where the guy kept demanding cycle accuracy and you came in to tell him it was pointless.
True, I actually meant to address that but the post was too long already. I've been over my feelings on this before, but I'll repeat them.
The faster a system gets, the less accuracy it needs. It's not even so much that we don't want that same degree of accuracy as it is that it's not really possible even if we did want it.
I would be absolutely floored if someone managed to successfully emulate all five pipelines stages of the N64 CPU. But even if he did, the system requirements would put it out of reach for casual gamers for decades to come.
These systems continue to get more and more complex, and fine grained precision becomes much harder, as well as less important. I guess if I had to define it, my goal is to do as much as possible, and be happy that it's all I could do.
Even I have to say "enough is enough" sometimes. It would take several months, or even years, of research to emulate hardware mul/div partial calculations resultant from reading the output registers too quickly. And zero commercial games do this, for the obvious reason that any game experiencing "bizarre" results would quickly find and fix their bug.
It doesn't mean I don't find it important. It doesn't mean I think it's pointless to try and emulate it. It just means I'm one person and I'm forced to allot my time to improve what I can. I choose to focus on the more important issues first.
And with the current state of N64 emulation, focusing on a cycle-accurate CPU core with full five-stage pipeline emulation is pretty low on the priority list.
We don't disagree nearly as much as you think.
I'm starting to see that. I apologize, you had so many comments on this massive accuracy push thing going on that it gave me the wrong impression.
Or do you mean to say that it would be a travesty if the game is supposed to have some bug on hardware that no longer exists?
I know we can never reach perfection. But I care enough to keep pushing forward and trying, where most others say "man, that's good enough." That's fine if you think it's good enough. Leave me be to keep going forward until I give up, too.
Don't take this as an insult, but I don't think BSNES makes as much of an effort towards efficiency as it could (yes, I've looked at the source...).
No, I agree, and have said as much. The CPU IRQ testing was based on being easy for me to work with. As it stands, that part of the code eats up over 40% of CPU time. It's very inefficient. Even the accuracy is a lot worse than it could be. I've also gone at length about that. The PPU renderer is such a joke that it's sad. But that at least boils down to lack of time more than lack of effort. Unfortunately, as a hobby, I still have to work a very demanding day job :/
I'm very upfront about the shortcomings, and I'm amazed people are as nice as they are. I really wish someone smarter than me would come along and show me up. I'm not looking to be the best, just to help push things forward.
I see this much more than I see "just use ZSNES, for this game it's fine."
Man. You know, I've been told that I've intentionally hacked a game to break in ZSNES, just to promote my emulator. Funny since the Japanese game has the same problem, but I digress. We certainly see very different things on the expansive internet.
I do agree that in principle preserving games is a more far reaching and significant goal than allowing people to play them now
That's just it. The goals co-exist! Work on an accurate emulator will tell you how the hardware really works. Now you can figure out the best way to create a faster emulator based on that knowledge. Both can exist at the same time! Like you said, worst case is you can comment it out in source code.
I look at current emulators that spend the better part of a decade patching bugs in games, which just cause new bugs in other games. And then timing changes end up breaking all the old hacks. And then you end up with hacks for games that don't need them. And you end up in this circle where you never make any real progress.
To me, it just seems like always sticking to hardware is best. To hell if your change is slow, and if it breaks a bunch of games. That's because something else is also wrong. Once you fix that, you'll get everything working in unison. No hacks, no guesswork.
From there, one can create an optimal emulator that runs on slower devices.
I know you don't think "non-accurate" emulators are worthless. Other people do. They've said this.
Yes, but people think slow emulators are worthless, too. You just have to ignore them, really. I know, much easier said than done. But there's always assholes in this world who can't do anything but insult someone for working their ass off to give them a product free of charge. Like me complaining about closed source emulators for instance. That's extremely annoying.
I don't know, maybe we have some sort of biological need to bitch about things that upset us. Where's that tcalludilig2 guy at when you need him? Need to get some Jung Psychology in here ;)
I think that we'd HAVE to eventually know that a closed source emulator is "cheating" or else it'd defeat a lot of what you're saying about preservation/accuracy, wouldn't it?
I don't know. Nobody knew SNESGT was soft-patching so many BS-X games. Most people were under the impression that it had vastly superior BS-X emulation. And hell, maybe it does. GIGO is an extremely intelligent guy. Can't tell without the source. But you can see the patching with the memory viewer if you know where to look.
But then, you really have no choice with the BS-X but to patch the games. There's really no other way to emulate a system like that; based on timed, real-life events, satellite transmissions; games that expired and games that could only be played during certain hours of the day. And games that are ridiculously rare. Not all are dumped, and many of those that are have been hacked for emulators already. I'm not at all faulting him for using hacks under these circumstances. It's just interesting how few know about them.
Really, I'm not against what you do. I don't really know exactly how to say this, because I do respect you a lot and actually agree with you more than you may be aware. I'm sorry if you took this personally because it actually wasn't directed at you - and I think you've even responded to some of the people I do have issue with in a way similar to how I would have responded.
Thank you. I didn't really take it too personally, no worries. I know I'm mostly responsible for the anti-hack push around the SNES scene, so I kind of take it upon myself to defend the other side here.
I don't think that I take an opposite stance to yours when it comes to how I want to do an emulator
That's cool. Look me up if you ever try an SNES handheld emulator. Perhaps I can be of some assistance.
Basically, this is the approach I take: sometimes it's very likely that no game will rely on a particular behavior, a behavior that may be complex to emulate and at a high performance cost. If this kind of problem does come up then it can be rectified then.
Well, if I understand how that behavior works, I'll add it even when no game (that we know of) relies on it. I've added a lot like that. IRQB timing, mode 7 extbg mosaic glitch, half-height OAM sprite glitch, etc etc.
But if I know it'll take too much time to figure out, and I know of nothing that relies on it, I will focus on more important issues before coming back to it. Not much choice, with limited resources you have to make painful compromises sometimes.
Sometimes this involves modeling something that isn't based on correct information to begin with and actually ends up hurting accuracy more than it helps it
And you learn it's incorrect by implementing it and seeing when it breaks something. That's just part of the process. The alternative is to ignore it and never get it right.
I
had perceived 100% compatibility for months, yet I kept changing things that could potentially break games anyway. But in doing so, I've probably fixed some bugs that were just as-yet undiscovered.
I don't think that faster computers is the only reason that an emulator like BSNES was started when it was as opposed to earlier on.
The only reason I didn't start sooner was because I doubted myself too much. I didn't think I'd ever get a single commercial game playing. I seriously overestimated the difficulty of writing an emulator.
I think that the bigger contributor is that it took a lot of time for the dust to settle on the details of the SNES for anyone to really be confident enough to even try for this level of acccuracy.
I disagree. SNES memory access timings were figured out in 2003. DRAM refresh timing in 2001 or so. PPU long dots and the short scanline and such were known from the NES days. The cycle-level breakdown of the 65816 was documented by WDC back in 1997. Nobody tried adding them until 2005, perhaps because they were perceived to not be too important, or perhaps because they were thought to be too complex.
I think a lot of it was that the original SNES emu authors left (zsKnight, _Demo_, Jeremy Koot and Gary Henderson), and the new maintainers weren't too confident about ripping out the core of an emulator to replace it. And it'd defeat the purpose to start over.
But that's speculation, too. We can always ask them directly, can't we? ;)
If someone tried to do a perfectly accurate XBox emulator right now they'd probably drive themselves insane with the complexity of getting the CPU timing right (which as far as I'm aware is not 100% publicly documented, unlike older CPUs). It would be very slow, but it'd also be very complex and most likely very unnecessary.
Agreed completely. I honestly don't believe we'll ever see a perfectly accurate Xbox emulator. It's just too complex for the few people that get involved in writing emulators to ever figure out. People in the fifth generation and above need to realize this :/
We're really pushing it with the fourth generation as it is ... but I think it's doable with the SNES. I just don't think I can do it alone. And I'm deeply saddened that I appear to be the last one left working on it (sans blargg's recent breathtakingly awesome S-DSP research). Or at least, nobody else working on this is talking to me about it ...
.