Over-accuracy debate

[I.S.T.]

Wine is a translator, not an emulator(Hell, the name stands for Wine Is Not an Emulator).

Other than that, it seems I was wrong. Still, my overall point stands. >.>

[Exophase]

Wine is a translator, not an emulator(Hell, the name stands for Wine Is Not an Emulator).

Other than that, it seems I was wrong. Still, my overall point stands. >.>

It's purely high level emulation on top of native code execution. It's principally the same thing as CXBX. You might also consider it a "software emulator" as opposed to a "hardware emulator."

I once went into #wine and told them that I think it really is an emulator. The response I got was "Yeah, you're right, we just call it that because we don't want people to think it's slow."

[Gil_Hamilton]

Lame Ain't an MP3 Encoder, right?

Oh, the sentiments of "I want this to just work without configuration" - back in the day I remember doing whatever it took to try to get games to run well. A little tweaking in a GUI before setting off on a 50 hour PS1 RPG was nothing in comparison. And well worth it. This doesn't sound like being a purist, it just sounds like being lazy. If you love the games it'll be worth putting in a little work to play them again, IMO.

It's not again, since I never owned an N64. That may be part of it.

Of course, if I DID own an N64 at one point, I'd STILL own one today, and emulation of the games I loved would be a moot point. Emulation's always been about trying things I never had the chance to before.



There's enough other games I can try on enough other platforms that it's not worth hassling with this one. Even the Saturn is within easy reach nowadays.


If I want to mess around with configuring things, I can set up a DOS machine and play old PC games. Or, as mudlord says, I can use MESS(which never fails to live up to it's name, from an interface standpoint).

[funkyass]

WINE is more like an adaptor than a translator.

[Exophase]

Lame Ain't an MP3 Encoder, right?

I was thinking the same thing XD I always hoped that that was a deliberate parody of the recursive acronym fad (which always struck me as lazy naming that stopped being neat after the first attempt) and the "X is not Y" naming scheme, to go so far as to outright lie about what it is.. heheh.. classic.

Of course, if I DID own an N64 at one point, I'd STILL own one today, and emulation of the games I loved would be a moot point. Emulation's always been about trying things I never had the chance to before.

There's enough other games I can try on enough other platforms that it's not worth hassling with this one. Even the Saturn is within easy reach nowadays.

If I want to mess around with configuring things, I can set up a DOS machine and play old PC games. Or, as mudlord says, I can use MESS(which never fails to live up to it's name, from an interface standpoint).

Okay, that's pretty fair. I'm not going to go through a hassle to setup stuff I have no prior experience with either, unless I have some good idea of what I'm getting into. I guess it'd take already knowing that it's a fun game to really want to do any of that. I actually rarely did anything with N64 emulation beyond Corn and UltraHLE, back when the shock factor alone was worth a massive amount to me (and it actually didn't take a lot of setting up, just not a lot really worked either)... I was such a hopeless, excited emulation fanboy back in the day. Now I'm all "PS2 emulation.. okay?"

Nice one on MESS.. heh :>

[Gil_Hamilton]

Lame Ain't an MP3 Encoder, right?

I was thinking the same thing XD I always hoped that that was a deliberate parody of the recursive acronym fad (which always struck me as lazy naming that stopped being neat after the first attempt) and the "X is not Y" naming scheme, to go so far as to outright lie about what it is.. heheh.. classic.

As I understand it, originally it WASN'T an MP3 encoder, just a set of patches you could apply to the source of an MP3 encoder to improve it.

Clearly, as time went on, it changed.

Of course, if I DID own an N64 at one point, I'd STILL own one today, and emulation of the games I loved would be a moot point. Emulation's always been about trying things I never had the chance to before.

There's enough other games I can try on enough other platforms that it's not worth hassling with this one. Even the Saturn is within easy reach nowadays.

If I want to mess around with configuring things, I can set up a DOS machine and play old PC games. Or, as mudlord says, I can use MESS(which never fails to live up to it's name, from an interface standpoint).

Okay, that's pretty fair. I'm not going to go through a hassle to setup stuff I have no prior experience with either, unless I have some good idea of what I'm getting into. I guess it'd take already knowing that it's a fun game to really want to do any of that. I actually rarely did anything with N64 emulation beyond Corn and UltraHLE, back when the shock factor alone was worth a massive amount to me (and it actually didn't take a lot of setting up, just not a lot really worked either)... I was such a hopeless, excited emulation fanboy back in the day. Now I'm all "PS2 emulation.. okay?"

Nice one on MESS.. heh :>

Ah, to be young again.
"You can play Nintendo games on a PC?!?! AWESOME!!!!"


Between NES emus and Scorched Earth... let's just say that many a class period was burned back in high school. Oh yeah, and the occasional Genesis game... KGEN98, whoo!
Sadly, the school's 66MHz Pentiums weren't up to SNES emulation.

[etabeta]

Unless MESS is actually seeing development work.

http://moogle-tech.com/blog/

sooner or later those improvements will be included in the MESS source.

p.s. I use MESS from command line and I'm very happy with it. Once you setup all the configuration you like in the .ini file (MAME/MESS equivalent of .cfg file), you simply have to type

Code: Select all

./mess system -cart gamename

which is not that annoying (nor is exactly rocket science, whoever can do that )
In game, if you don't want to restart, you can simply press TAB and you can change game and part of the settings through an interface a bit worse than the ZSNES one, but more or less equivalent (for other configurations, restart is necessary because not all the options are so easily accessible: in this ZSNES old fashioned UI wins by far )...
but if you cannot live without a nice UI, then you're right: it is not the more user friendly thing ever seen (and it's Windows only atm)

[Neo Kaiser]

I always notice that almost all the emulators start speed oriented and then change to accuracy orientation. It is like that speed is step 1 and accuracy is step 2.

[Exophase]

I always notice that almost all the emulators start speed oriented and then change to accuracy orientation. It is like that speed is step 1 and accuracy is step 2.

The slower an emulator is the longer it'll take to test anything in it, which is vital in making it more accurate (even the ability to test at accelerated speeds beyond what it'd normally play it are helpful)

[AamirM]

Hi,

I think most newer emus all started as accuracy oriented. The older ones (like ZSNES, Snes9x etc...) started as speed oriented because that was demanded back then but now are becoming accuracy oriented because thats what is demanded now. In Regen, I went for accuracy and speed both (you will soon see a newer version which is much more faster). But I have never sacrificed accuracy for speed.

stay safe,

AamirM

[Exophase]

Hi,

I think most newer emus all started as accuracy oriented. The older ones (like ZSNES, Snes9x etc...) started as speed oriented because that was demanded back then but now are becoming accuracy oriented because thats what is demanded now. In Regen, I went for accuracy and speed both (you will soon see a newer version which is much more faster). But I have never sacrificed accuracy for speed.

stay safe,

AamirM

Although I do think what you're saying is true (that emulators now tend to be more accuracy oriented from the start), I don't think that it's just because speed was demanded back then. Writing efficient emulators is challenging, fun, and rewarding, and there was a lot of competition to this end back in the day. There's not a lot of competition with accuracy, since it makes much more sense to openly share data.

Unfortunately I think that a lot of the efficiency loving type of emulator programmers are gone forever

[Gil_Hamilton]

Unless MESS is actually seeing development work.

http://moogle-tech.com/blog/

sooner or later those improvements will be included in the MESS source.

Spiffy!

[mudlord]

Hopefully you'll not be as upset in the future, as I really do value your unique skill and assistance with things. I'd still like to return the favor for your help one day, too.

I'm not now. Its nice to completely forget about things for a couple of hours, and come back when everything is fresh . I guess I overreacted a bit and I apologise.

And no probs, I don't mind helping you out. I'm just glad BSNES has decent OGL support.

You're right, bullshit was too strong a word. I apologize for that.

I'll be honest and say that I find wrapping an API to not be a very sound development strategy, but I can see the rationale for not wanting to start from scratch, too. It is a hobby, after all.

Yes, I'd have to agree. But there's not much we can do otherwise, other than rewriting the whole thing for a different API. And the developer still sees use in thier out of date vid card, so what can we do?

If you truly believe there's a perceived bias against you here, then I ask that we please continue this discussion in private.

No need. Lets bury the hatchet so to speak. This arguing gets nowhere, and plus it deviates wildly from the main discussion at hand, which is about speed versus accuracy itself.

[Nightcrawler]

Say you have emulator A and emulator B...

Emulator A runs 100% of all games with cycle accuracy.
Emulator B runs 100% of all games with 9,999 hacks.

Now.. is there any difference between the two for 99% of the fanbase? Not really. Both would be equally likely to be used.

Now, let's say Emulator B now has savestates and runs 200% faster than emulator A!

Now.. is there any is there any difference between the two for 99% of the fanbase? Yes.. Now, most would use emulator B. Other people who do more than what all known games do would still go with emulator A.


You see, there's different people with different needs. There's a need for both emulator A and emulator B. With both emulators you have satisfied 100% of the fanbase (except for those who are never happy with anything).

I don't understand why this discussion is even taking place.

[byuu]

In this thread hardware accelerated implementations of video accelerators in consoles has been referred to as HLE.

You're right, I did this as well. My mistake. It's still somewhat high-level in that you replace actual math with high-level video card API functions, but it's certainly not the same thing as eg DSP HLE.

At any rate, aside from some of external chip emulation ZSNES is a thoroughly LLE emulator.

I'll agree, but I'd add that HLE vs LLE is not black and white. Every emulator is different to a degree.

Writing efficient emulators is challenging, fun, and rewarding, and there was a lot of competition to this end back in the day. There's not a lot of competition with accuracy, since it makes much more sense to openly share data.

Both groups can share information. Just the latter is usually more willing to.

Unfortunately I think that a lot of the efficiency loving type of emulator programmers are gone forever

They're around, they've just moved on to more demanding systems. Plenty of room for efficiency in PS2 emulation. Now we need to invent higher forms of HLE and recompilation :)

There's also good opportunity to do this for handhelds. We really need a decent SNES PSP emulator. The Snes9X port completely broke HDMA. and it doesnt' get full speed, either.

There's just not a lot of point in maintaining a pure assembler codebase that is hard to work with to emulate a 2MHz system when the slowest of slow computers can run it 20x faster than the original system.

Yes, I'd have to agree. But there's not much we can do otherwise, other than rewriting the whole thing for a different API. And the developer still sees use in thier out of date vid card, so what can we do?

Yeah, I agree. As long as the solution is transparent to the end user. The overall opinion in this thread is clear. Very few are dead-set against either form of emulation. It's just that everyone wants hassle free emulators.

Get a good database to apply HLE stuff transparently, and make sure the users don't have to download their own API wrappers, and you'll have something just about everyone will love.

No need. Lets bury the hatchet so to speak. This arguing gets nowhere, and plus it deviates wildly from the main discussion at hand, which is about speed versus accuracy itself.

Yay :D
Sounds good. The funny part is that we mostly agree on everything, we're just very sensitive about the words used. This really reminds me of the SNL skit where the two politicians are screaming and yelling at each other, saying the exact same things but worded differently.

A> "I believe that Americans want proper working environments and decent wages!!"
B> "That's preposterous! They want acceptable compensation and non-hazardous labor conditions!"
A> "They should have the right to free speech!!"
B> "No, what they should be allowed is to say whatever they like openly!"
A> "You sir, are an ignorant fool!"
B> "And you are a clueless simpleton!"

I don't understand why this discussion is even taking place.

Same reason all of these conversations happen. The majority usually stay out of things as they're already happy, but occasionally a few will say something disparaging to the minority, thus prompting them to band together and become more vocal to have their opinions heard. The majority still mostly stays uninvolved, thus leading to the appearance that the minority is more prominent than it seems. But a few in the majority will come in to defend their viewpoint, and usually neither side can see eye to eye. The problem boils down to people wanting only one solution to every problem, as if everything has an absolute truth. Many people just can't accept that they're both right. Nor can they strike a compromise in the middle.

You see it with everything: Windows v OSX, IE v Firefox, QWERTY v DVORAK, higher-level v lower-level programming languages, monolithic v microkernel, speed v accuracy, etc etc.

[Rashidi]

Emu A .vs. Emu B...

Emulator A runs 100% of all games with cycle accuracy.
Emulator B runs 100% of all games with 9,999 (and more) hacks.
...

I don't understand why this discussion is even taking place.

the problem with emu B, that has been said earlier, is possibilty of emerging new game (probably, homebrew), that defeat the current hacks of emu B, but of course adding more hacks to emu B might solve (or add new) teh problem...


while if the new (homebrew) game wont run properly on emu A, i'm sure there will be someone would say:

• ha, that game won't run properly on the real-thing anyway

regardless that new game may purposedly intended to be run on emu B...


i guess some ppl, fueled with fanaticism of their respective cult, just doesn't want to admit:

You see, there's different people with different needs. There's a need for both emulator A and emulator B.

[I.S.T.]

There's also good opportunity to do this for handhelds. We really need a decent SNES psp emulator. The Snes9X port completely broke HDMA. and it doesnt' get full speed, either.

We also need an emulator that runs on slow systems and blargg's audio code or something as accurate. That would wind up helping the PSP as well, I imagine.

[FitzRoy]

I don't understand the situation enough to gauge if bsnes could possibly be rewritten and simplified for hardware of that level. In other words, is it a difficulty or demand problem? I notice that a lot of Nintendo-based developers don't buy Sony hardware, but maybe 333mhz ARM is still too damn slow. Maybe it's better shooting for the Pandora or x86 Atom-based netbooks.

[Exophase]

There's also good opportunity to do this for handhelds. We really need a decent SNES psp emulator. The Snes9X port completely broke HDMA. and it doesnt' get full speed, either.

We also need an emulator that runs on slow systems and blargg's audio code or something as accurate. That would wind up helping the psp as well, I imagine.

Let's start with the basics, getting all of the actual graphical features of the PPU rendered correctly in software at little or no frameskip at 333MHz on PSP, or even 200-240MHz on GP2X. This is actually much harder than it sounds. That ZSNES (and other high performance SNES emulators - does anyone remember NLKSNES?) ever pulled off the performance it did is something of a miracle. x86 can do some things that these platforms can't, though, like unaligned writes (sounds small but it helps).

SNES9x, which is what's used in all of these handhelds, has okay rendering code (more optimized than VBA at any rate), but its approach is not a good fit for low-cache CPUs. Having main/sub color + zbuffers span the entire frame works out to several obligatory cache misses per group of pixels. The rendering is also optimized for full frame in other ways, which works well when nothing changes midframe, and works okay when only the logged things (such as scroll positions) are changed, but breaks down badly when things such as palette entries are changed several times a frame, because it has to evaluate all of the sprites in the region each time it does this. If it instead started with a line based renderer and optimized that (including sprite binning) then it might have slightly worse very best case performance, but it'd have much better worst case performance.

I've thought out rendering schemes for SNES down to most of the small details (reading BSNES's source helped give a good grasp on how the color blending works), but unfortunately I don't have it in me to rewrite a renderer for SNES9x or another emulator. If I do emulator work it pretty much has to be doing the entire emulator, and doing a decent SNES emulator would be difficult and very time consuming :\ Maybe one day though..

[Marty]

(and other high performance SNES emulators - does anyone remember NLKSNES?)

Ahh, I remember it. It ran blazingly fast on my 486DX2-66 back in the old days.

[Deathlike2]

NLKSNES didn't have 15-bit rendering IIRC, so of course it ran blazingly fast, but then there was the lack of transparancy (aka CT "fog bug"). IIRC, it didn't do audio at all as well. (I could be mistaken, but eventually ESNES and those that worked on NLKE merged into NLKE).

So yes, it's blazing fast, but did nothing important outside of being fast.

[Exophase]

NLKSNES didn't have 15-bit rendering IIRC, so of course it ran blazingly fast, but then there was the lack of transparancy (aka CT "fog bug"). IIRC, it didn't do audio at all as well. (I could be mistaken, but eventually ESNES and those that worked on NLKE merged into NLKE).

So yes, it's blazing fast, but did nothing important outside of being fast.

This was also long before anyone else supported subscreen rendering either (or non-8bpp output), even SNES9x. The point is that it was much faster than SNES9x was back then even when limited to the same feature sets.

NLKE just wasn't ever as fast as NLKSNES was, unfortunately.

[Deathlike2]

NLKSNES didn't have 15-bit rendering IIRC, so of course it ran blazingly fast, but then there was the lack of transparancy (aka CT "fog bug"). IIRC, it didn't do audio at all as well. (I could be mistaken, but eventually ESNES and those that worked on NLKE merged into NLKE).

So yes, it's blazing fast, but did nothing important outside of being fast.

This was also long before anyone else supported subscreen rendering either (or non-8bpp output), even SNES9x. The point is that it was much faster than SNES9x was back then even when limited to the same feature sets.

NLKE just wasn't ever as fast as NLKSNES was, unfortunately.

My history is fuzzy, but ZSNES had working transparancy at about that time, although not perfect for various reasons.

Snes9x had audio, NLKSNES did not. Those are not comparable.

NLKE did have ESNES's audio engine, so it is kind of difficult to compare both emus given that major difference.

Sound emulation is critical to game compatibility.

[Exophase]

My history is fuzzy, but ZSNES had working transparancy at about that time, although not perfect for various reasons.

NLKSNES was released long before the first version of ZSNES was.

Snes9x had audio, NLKSNES did not. Those are not comparable.

NLKE did have ESNES's audio engine, so it is kind of difficult to compare both emus given that major difference.

Sound emulation is critical to game compatibility.

Audio does not affect rendering speed. NLKSNES was much faster than SNES97 and ESNES with audio disabled. NLKE must have changed the rendering engine because it took a major speed hit, in the same circumstances w/o blending.

[Deathlike2]

My history is fuzzy, but ZSNES had working transparancy at about that time, although not perfect for various reasons.

NLKSNES was released long before the first version of ZSNES was.

I wasn't around emulation when NLKSNES started. However, I paid some attention when it merged with ESNES at that time. It helps to put a reference to time when referring to old emus.

Snes9x had audio, NLKSNES did not. Those are not comparable.

NLKE did have ESNES's audio engine, so it is kind of difficult to compare both emus given that major difference.

Sound emulation is critical to game compatibility.

Audio does not affect rendering speed. NLKSNES was much faster than SNES97 and ESNES with audio disabled. NLKE must have changed the rendering engine because it took a major speed hit, in the same circumstances w/o blending.

Emulating the SPC does increase CPU load, which in turn does affect rendering speed.