Over-accuracy debate

[King Of Chaos]

I've read people saying Gens being crap because it can't compare to Kega in some games. I beg to people to differ.

Well, the majority of people don't like Gens because a) they're smart enough to realize what Gens is doing completely wrong, b) Gens really can't technically compare to Kega, or c) they realize there's better emulators out there. Besides, there's some questionable things Gens does, that makes it seem more hackish to me than anything. Steve Snake knows the Genesis/32X/Sega CD hardware more than anyone else does or ever will, and he's shown that in Kega.

Now, why do I say Gens does some questionable things? Well, for example, the Gens Pro Action Replay nightmare. Why don't codes created in Kega and the real hardware work in Gens? It's because the 68k core used in Gens swaps the bytes internally to match x86's endianness. The intention of doing this is obviously a speed up. I've asked Stef in the past to correct this, but sadly I'm not sure this will happen. This is just one example of things people don't like about Gens. Now if somebody would fix Gens and make it all fully accurate, that'd greatly help people.

I believe in honest emulation. Accuracy over speed. Full hardware/game support over hacks. If you're going to write an emulator, you have to do it right. You get the idea. Even though many users don't give a damn about accuracy as long as they get to play games, but I do care about accuracy as many others here do.

And the whole Kega slow speed thing shouldn't really be a problem with modern computers since Kega will run games at full speed for them, as will Regen on fast modern computers.

[AamirM]

Hi,

Well, the majority of people don't like Gens because a) they're smart enough to realize what Gens is doing completely wrong, b) Gens really can't technically compare to Kega, or c) they realize there's better emulators out there. Besides, there's some questionable things Gens does, that makes it seem more hackish to me than anything. Steve Snake knows the Genesis/32X/Sega CD hardware more than anyone else does or ever will, and he's shown that in Kega.

But that doesn't mean they have to say disrespectful things about it. I think they have completely forgotten that it was the best emu for a very long time.

BTW, I haven't come across any hacks in Gens. What seems hackish to you?

stay safe,

AamirM

[neo_bahamut1985]

Well, I did find it rather strange how Gens can use save/load states with Sega CD games while Kega didn't have that feature. But on the other hand, Kega (and Regen) both have better Yamaha YM2612 emulation.

[creaothceann]

Well, I did find it rather strange how Gens can use save/load states with Sega CD games while Kega didn't have that feature.

I don't know about current SEGA emulation, but maybe that area is still in development so a definite savestate format is not yet possible?

[Dullaron]

I like Regen better though.

Nobody isn't working on Kega anymore as it seem. Last update was the 2006/01/06 on the release. It seem dead now.

[Deathlike2]

I've read people saying Gens being crap because it can't compare to Kega in some games. I beg to people to differ.

I believe in honest emulation. Accuracy over speed. Full hardware/game support over hacks. If you're going to write an emulator, you have to do it right. You get the idea. Even though many users don't give a damn about accuracy as long as they get to play games, but I do care about accuracy as many others here do.

That's not usually going to happen early in research/development in the emulation of a console. Until the majority of the info is complete, it always "appears" as one big hack until then.

[byuu]

I know you are taking a swing at me here, but let me say this:

I didn't specifically think of your name one time while writing that. In fact, I'm only aware of your work on GBA emulation.

If you happen to see a nice video plugin, would you like to rewrite a entirely new piece of software that mimics the behaviour of what that previous software is?

Again, it depends upon my intention. Do I want the games working now, at playable speeds, on modern hardware? Or do I want to understand how the hardware works at the lowest level, to document it for the future when Glide, OpenGL2, etc are all long since deprecated and not supported by drivers?

So why is a wrapper such a big fucking deal?

It isn't, and I never said that it was.

Then you talk about the problem with replicating graphics effects with hardware. Isn't that the nature of HLE, or do you know some better approaches?

No, like you said, that's the nature of HLE. The only alternative is LLE, which also has serious problems.

Or why don't we use a software renderer that goes < 20 FPS, and the general public yells at us for it due to quality and speed.

Again, the general public will bitch regardless. How about we do what we want, and ignore them?

Bye.

I seriously don't know why you're so pissed off at me. If you read my other posts, you'd understand my point.

We all have opinions on how things should be done. Opinions don't mean shit, unless you're actually working on something. Am I working on N64 emulation? No, so my opinion doesn't matter.

1) HLE works for now, yes. It gets games playable now. But it has the problem that video card APIs will become deprecated in time. Thus, it's a temporary fix. Do you agree or disagree with that?

2) LLE gets around this by implementing the raw drawing routines in pure math. Math will never become deprecated, so once we have a software implementation, it will work for all time. The problem is that it's ridiculously slow, and not at all feasible for playing games today. However, it is the superior solution for when PCs are 5x faster than they are today. Do you agree?

I'm not saying that people using HLE are wrong. I can understand that nobody would want to write an emulator they couldn't even play because it was too slow for any existing hardware. I understand that HLE is the best (and let's be honest -- only) possible choice for today's hardware. My only point is that it's not a permanent solution. Surely you can agree with that. Eventually, the work will have to be discarded. That, or you'll have to keep porting the Glide wrapper to newer and newer APIs into perpetuity.

Or perhaps it's best to just keep up with the wrappers until PCs are fast enough, and then focus on a pure software implementation at that time. I don't claim to have a magical solution to make everyone happy. PCs are too slow for low level emulation, so compromises are mandatory. You're going to take slack from people no matter which option you choose, and there's nothing you can do but ignore it.

But I'm not the one being verbally abusive about your choice of compromise, and I respect your decision, so you have no reason to be upset with me. I'm just stating the very real, very obvious to anyone, compromises that are being made. If that upsets you, then it's your problem, and not mine.

[King Of Chaos]

Hi,

Well, the majority of people don't like Gens because a) they're smart enough to realize what Gens is doing completely wrong, b) Gens really can't technically compare to Kega, or c) they realize there's better emulators out there. Besides, there's some questionable things Gens does, that makes it seem more hackish to me than anything. Steve Snake knows the Genesis/32X/Sega CD hardware more than anyone else does or ever will, and he's shown that in Kega.

But that doesn't mean they have to say disrespectful things about it. I think they have completely forgotten that it was the best emu for a very long time.

BTW, I haven't come across any hacks in Gens. What seems hackish to you?

stay safe,

AamirM

See example about the PAR, as I consider this a hack. I also have my suspicions about the StarScream core. I'll have to look into this later as I haven't used Gens in a LONG time. And don't forget Genecyst and KGen.

Well, I did find it rather strange how Gens can use save/load states with Sega CD games while Kega didn't have that feature. But on the other hand, Kega (and Regen) both have better Yamaha YM2612 emulation.

Because that was done after the last Kega release. Steve Snake has said supporting this would be a technical challenge and it is. The save state support for Sega CD in Gens is buggy at best, and the majority of the time it doesn't work. I know why this is, but I don't want to get into this at the moment.

Nobody isn't working on Kega anymore as it seem. Last update was the 2006/01/06 on the release. It seem dead now.

Search around on forums. Kega isn't dead, it's been sleeping. Steve Snake has had a bad couple of years with real life, hence the lack of updates. When he gets his life in order, expect great things.

[Exophase]

Well, the majority of people don't like Gens because a) they're smart enough to realize what Gens is doing completely wrong, b) Gens really can't technically compare to Kega, or c) they realize there's better emulators out there.

You basically just repeated the same thing three times without actually saying anything. And bringing intellect into it is pretty low. Maybe some people are smart enough to realize that if an emulator does everything they want it to then there's no reason wasting their time replacing it with another one.

Steve Snake knows the Genesis/32X/Sega CD hardware more than anyone else does or ever will, and he's shown that in Kega.

How has Steve Snake shown that no one will ever surpass his knowledge of these Sega platforms? This kind of short sighted/one-sided comment really shows your bias on the matter. I certainly hope that for the sake of Genesis preservation that he does not know more than anyone ever will because he hasn't exactly been sharing information left and right. There are a number of people who are investigating Genesis hardware right now and with their findings combined I really doubt any one single person can stand against it for long. Even the venerable Charles MacDonald is probably not done with his Genesis research (and this makes its way back into GenesisPlus too).

I believe in honest emulation. Accuracy over speed. Full hardware/game support over hacks. If you're going to write an emulator, you have to do it right. You get the idea. Even though many users don't give a damn about accuracy as long as they get to play games, but I do care about accuracy as many others here do.

I think this is the kind of attitude that byuu and myself are not really thrilled with. Calling an emulator "dishonest" and saying that emulators "have to" do it "right" is very loaded. What's worse is that the only concrete strike you gave against Gens is the format of Pro-Action Replay codes. To call this an accuracy problem (as opposed to an interface issue) is really reaching. The game will never be able to determine that memory is being byte swapped (this is another good example of "higher level" winning out). If Gens bothered to merely change the internal representation after you entered the codes as opposed to requiring that you enter them swapped then this would never have even been an issue. This is a trivial oversight that you're making out to be a critical flaw. Criticizing byte swapping, a legitimate optimization that if done correctly does not hinder accuracy, makes you look ignorant.

I hope people understand why I'm frustrated with this. I get the feeling that if I came in here and released an emulator and claimed it was the most accurate of its kind (or intended to be) I would be lavished in praise, but if I claimed I was doing it for speed I'd get much less respect, possibly even criticized. The funny thing is that the speed oriented one could be even MORE accurate than the one I claim to be accuracy oriented and I doubt anyone would even care, possibly even notice. Some of these people probably don't write emulators and may not even understand how they work at all (this has been proven in the past).

The "brand loyalty"/favoritism towards particular emulators doesn't help either. It seems some people need to feel like they've been using the best all these years and have to prove it to everyone else.

[Gil_Hamilton]

No, but I believe that's already been addressed by the wrapper, which is easy as hell to use.

So the best N64 video emulation comes from wrapping N64 calls to Voodoo calls, then wrapping THOSE calls to OpenGL calls?


Thanks for reminding me why I don't mess with N64 emulation.
Per-game configs and Rube Goldberg stacking of wrappers isn't worth the hassle.


Someone tell me when there's a nice plug&play N64 emu that just works.

The "brand loyalty"/favoritism towards particular emulators doesn't help either. It seems some people need to feel like they've been using the best all these years and have to prove it to everyone else.

Yeah, I really never understood that aspect.

I've always used ZSNES(Interface preference, mainly. Though when I first got into SNES emulation the choice was based on which one ran full speed on my lower-end computer back in '99-2K), but was more than willing to point people towards SNES9x.


And for all it's accuracy, I probably wouldn't recommend bSNES to the average user right now.
Coprocessor and state support would probably mean more to them than the most accurate base system emulation currently available would.

[DancemasterGlenn]

Doesn't really contribute anything substantial, but last night I was installing some emulators on my friend's computer, so he could relive some of his childhood favorites, and I opted for zsnes over bsnes. He likes how the gui looks (though I guess he shouldn't get used to it :P), and it works on his system. He doesn't have any idea about accuracy vs. speed, and frankly I think he's better off that way. If he had a crazy new system I might have shown him bsnes, but I knew zsnes would "just work".

Zsnes was my first emulator, and will probably continue to be my favorite if only for nostalgia's sake. By the same token, I'm very proud to be on a forum where I can see byuu in action, and it feels great to be a part of the bsnes community as well.

[FitzRoy]

I think you're just overreacting in general to a common and irresolvable problem, Exophase. Yes, people have strong opinions about things they don't understand, sometimes to the point of antagonism and mockery. Yes, people are largely ungrateful. Yes, people try to turn preferences into ideological movements. All you can do is ignore it or address it on a per-case basis. And I'm sure we've all been guilty of it at some point when we were young and bored. If you can prevent these all from happening ever again with a thread on the zsnes board, you'll get the peace prize for sure.

[whicker]

Meh, I just like it when people explain things in detail. Unfortunately, everyone here only seems to do so when insulted or angered.

[Exophase]

I think you're just overreacting in general to a common and irresolvable problem, Exophase. Yes, people have strong opinions about things they don't understand, sometimes to the point of antagonism and mockery. Yes, people are largely ungrateful. Yes, people try to turn preferences into ideological movements. All you can do is ignore it or address it on a per-case basis. And I'm sure we've all been guilty of it at some point when we were young and bored. If you can prevent these all from happening ever again with a thread on the zsnes board, you'll get the peace prize for sure.

If it means anything, I didn't start this topic on its own, it was split off from another one :<

[mudlord]

I didn't specifically think of your name one time while writing that. In fact, I'm only aware of your work on GBA emulation.

Alright, but it has a obvious slanting, since I have been working on that thing for over a year....

Again, it depends upon my intention. Do I want the games working now, at playable speeds, on modern hardware? Or do I want to understand how the hardware works at the lowest level, to document it for the future when Glide, OpenGL2, etc are all long since deprecated and not supported by drivers?

Your right. I guess then our intention was to get stuff working now, on modern hardware. Which seems by your statement above is ill advised.

It isn't, and I never said that it was.

You refer to "wrapper bullshit". Which in laymans term's, suggests it is....

No, like you said, that's the nature of HLE. The only alternative is LLE, which also has serious problems.

Yup. There is serious issues when doing rasterization. Early versions of PJ64 1.7 showed that.

Again, the general public will bitch regardless. How about we do what we want, and ignore them?

Because some of us do worry about what the public thinks. I know I do care about what others think of my code.

I seriously don't know why you're so pissed off at me. If you read my other posts, you'd understand my point.

And I did read your previous posts, yet I am more than pissed off at you. And I do understand your point, but you did attack me, which is one thing that pisses me off royally. So what the hell I am meant to do, let it slide, due to your position in the emulation community?

We all have opinions on how things should be done. Opinions don't mean shit, unless you're actually working on something. Am I working on N64 emulation? No, so my opinion doesn't matter.

Wrong. Your opinion does matter, due to your status in the scene. So what you say, does carry weight.

HLE works for now, yes. It gets games playable now. But it has the problem that video card APIs will become deprecated in time. Thus, it's a temporary fix. Do you agree or disagree with that?

Yes, I agree.

LLE gets around this by implementing the raw drawing routines in pure math. Math will never become deprecated, so once we have a software implementation, it will work for all time. The problem is that it's ridiculously slow, and not at all feasible for playing games today. However, it is the superior solution for when PCs are 5x faster than they are today. Do you agree?

Yes, I agree.

I'm not saying that people using HLE are wrong. I can understand that nobody would want to write an emulator they couldn't even play because it was too slow for any existing hardware. I understand that HLE is the best (and let's be honest -- only) possible choice for today's hardware. My only point is that it's not a permanent solution. Surely you can agree with that. Eventually, the work will have to be discarded. That, or you'll have to keep porting the Glide wrapper to newer and newer APIs into perpetuity.

Yes, OR in time, we switch to LLE when it is technically feasible, like you said before. I think that's a reasonable approach. What I don't get is why people are so pissed off that its not happening now when the hardware isn't able to do it at a decent speed.

Or perhaps it's best to just keep up with the wrappers until PCs are fast enough, and then focus on a pure software implementation at that time.

Yes, sounds reasonable.

But I'm not the one being verbally abusive about your choice of compromise, and I respect your decision, so you have no reason to be upset with me.

Who needs enemies, hey?

Bye.

I think this is the kind of attitude that byuu and myself are not really thrilled with. Calling an emulator "dishonest" and saying that emulators "have to" do it "right" is very loaded.

Same here, another thing that pisses me off with the scene.

So the best N64 video emulation comes from wrapping N64 calls to Voodoo calls, then wrapping THOSE calls to OpenGL calls?

Thanks for reminding me why I don't mess with N64 emulation.
Per-game configs and Rube Goldberg stacking of wrappers isn't worth the hassle.

Someone tell me when there's a nice plug&play N64 emu that just works.

If you want, go try MAME/MESS. That should be adequate, considering your purist approach and disgust with HLE.

[I.S.T.]

No, but I believe that's already been addressed by the wrapper, which is easy as hell to use.

So the best N64 video emulation comes from wrapping N64 calls to Voodoo calls, then wrapping THOSE calls to OpenGL calls?


Thanks for reminding me why I don't mess with N64 emulation.
Per-game configs and Rube Goldberg stacking of wrappers isn't worth the hassle.


Someone tell me when there's a nice plug&play N64 emu that just works.

Glide 64 will run most games without having to worry about that crap. It's basically the n64 equivalent of the P.E.Op.S. software plugin in terms of how compatible it is.

[mudlord]

Glide 64 will run most games without having to worry about that crap. It's basically the n64 equivalent of the P.E.Op.S. software plugin in terms of how compatible it is.

Sorry, he won't buy that. It HAS to be LLE or nothing at all. AND it must be self contained.

[I.S.T.]

Glide 64 will run most games without having to worry about that crap. It's basically the n64 equivalent of the P.E.Op.S. software plugin in terms of how compatible it is.

Sorry, he won't buy that. It HAS to be LLE or nothing at all. AND it must be self contained.

He wasn't saying that. Hell, he even admits he uses zsnes most of the time, and that's not close to LLE. >.>

I can see why he'd be frustrated with the different settings for each game deal. PSX emulation was like that for a while, and several n64 games are still in that territory.

[byuu]

One thing from earlier I wanted to add ... another positive thing about NESdev is that even if some people can't afford very old, very expensive copiers and testing rigs ... even by just having fun trying their hand at writing an emulator anyway, it does turn out some really intelligent people who can assist with general problems. I've gotten a lot of very important help from all of them.

And really, I mean ... no, it's not nice to attack another emu author, but at the same time ... when in Rome. You really shouldn't go to a forum dedicated to meticulous emulation and ask about hacks. And vice versa. That's just asking for trouble.

If you're going to write an emulator, you have to do it right.

Meh, I think it's up to the author to decide how he wants to do it. I'm honestly most happy having two active approaches.

Keep one emulator focused on speed and features so that people can play games today, and another on accuracy so that the future has the best emulation possible. And if people would stop trying to compare them as though they were competing, that would be perfect to me.

You refer to "wrapper bullshit". Which in laymans term's, suggests it is....

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.

And I did read your previous posts, yet I am more than pissed off at you. And I do understand your point, but you did attack me, which is one thing that pisses me off royally.

I'm sorry you're still upset, but there's nothing I can do about that. 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.

So what the hell I am meant to do, let it slide, due to your position in the emulation community? Wrong. Your opinion does matter, due to your status in the scene. So what you say, does carry weight.

...

I'm really sick of hearing about how "important" I am. If anything, that is patronizing to those who agree with me. It indirectly implies them to be yesmen.

It's also far from the truth. I most certainly have just as many critics as I do supporters.

I believe everyone here can think for themselves, and can separate fact from opinion. We all have a reputation which is built upon our previous actions. I'm deeply flattered that I appear to have a good one here. And I certainly hope that both my strengths and weaknesses are considered on matters of absolute truth. But I don't believe for a second that anyone here blindly follows my opinions on things, just because I say them. And if someone does, then I'm disappointed in them, but there's nothing I can do about that. Reputation has nothing to do with personal opinions. And the speed vs accuracy debate is just that, a lot of personal opinions.

I'm saddened that you felt the need to bring this up in our disagreement. My earlier words were a bit harsh, and for that I apologize. I'm just a very direct person is all, and I will always be true to myself and speak my mind. If you truly believe there's a perceived bias against you here, then I ask that we please continue this discussion in private.

[I.S.T.]

I believe in honest emulation. Accuracy over speed. Full hardware/game support over hacks. If you're going to write an emulator, you have to do it right. You get the idea. Even though many users don't give a damn about accuracy as long as they get to play games, but I do care about accuracy as many others here do.

You're looking at things in black and white. When it comes to making an emulator, it's not all or nothing. You must make compromises somewhere along the way.

Accuracy is good. We all know this. However, with accuracy comes a cost. You sure as shit wouldn't want a mega accurate PS2 emulator. It'd take a frigging supercomputer to work at a playable speed!

[Gil_Hamilton]

So the best N64 video emulation comes from wrapping N64 calls to Voodoo calls, then wrapping THOSE calls to OpenGL calls?

Thanks for reminding me why I don't mess with N64 emulation.
Per-game configs and Rube Goldberg stacking of wrappers isn't worth the hassle.

Someone tell me when there's a nice plug&play N64 emu that just works.

If you want, go try MAME/MESS. That should be adequate, considering your purist approach and disgust with HLE.

Glide 64 will run most games without having to worry about that crap. It's basically the n64 equivalent of the P.E.Op.S. software plugin in terms of how compatible it is.

Sorry, he won't buy that. It HAS to be LLE or nothing at all. AND it must be self contained.

First off, thank you for putting words in my mouth.
I notice you didn't deride sweener back on page 1 for having the same attitude.


This isn't about speed VS accuracy. It's about usability and sanity.


Give me an emulator that "just works" and I won't ask how it "just works."
I'll be disappointed when I run into something that doesn't, but it's no big deal, there's other games out there.


Give me an emulator that expects me to research and download 3rd-party plugins, the best of which requires YET ANOTHER 3rd-party app, and then has a huge text file full of hacks that STILL doesn't play several games I want(I just checked the hacks file, and probably the first thing I would've tried would've been unplayable)... I'm going to laugh.


I play games to have fun. Not to get headaches farting with the emulator.

I largely gave up on PS1 emulation for a long time for similar reasons.

No, but I believe that's already been addressed by the wrapper, which is easy as hell to use.

So the best N64 video emulation comes from wrapping N64 calls to Voodoo calls, then wrapping THOSE calls to OpenGL calls?


Thanks for reminding me why I don't mess with N64 emulation.
Per-game configs and Rube Goldberg stacking of wrappers isn't worth the hassle.


Someone tell me when there's a nice plug&play N64 emu that just works.

Glide 64 will run most games without having to worry about that crap. It's basically the n64 equivalent of the P.E.Op.S. software plugin in terms of how compatible it is.

Interesting you mention that...
Pete's plugins didn't treat me very well.
The software one wouldn't display the RType Delta pause menu properly. The hardware one wouldn't give me a decent Super Robot Wars F picture no matter what I did.

I really couldn't get a very good 2D game image out of either one.


IMO, Elsimi's(or however it was spelled) was a lot nicer, for what it worked with.
But those last 5 words were the problem.

[mudlord]

First off, thank you for putting words in my mouth.

No problem.

Give me an emulator that "just works" and I won't ask how it "just works."
I'll be disappointed when I run into something that doesn't, but it's no big deal, there's other games out there.

In that case, wait for MAME/MESS to have decent N64 emulation.

Give me an emulator that expects me to research and download 3rd-party plugins, the best of which requires YET ANOTHER 3rd-party app, and then has a huge text file full of hacks that STILL doesn't play several games I want(I just checked the hacks file, and probably the first thing I would've tried would've been unplayable)... I'm going to laugh.

Read what I said above. And don't fucking bother with HLE.

I play games to have fun.

Don't we all?

..well most of us.

Bye.

[I.S.T.]

No, but I believe that's already been addressed by the wrapper, which is easy as hell to use.

So the best N64 video emulation comes from wrapping N64 calls to Voodoo calls, then wrapping THOSE calls to OpenGL calls?


Thanks for reminding me why I don't mess with N64 emulation.
Per-game configs and Rube Goldberg stacking of wrappers isn't worth the hassle.


Someone tell me when there's a nice plug&play N64 emu that just works.

Glide 64 will run most games without having to worry about that crap. It's basically the n64 equivalent of the P.E.Op.S. software plugin in terms of how compatible it is.

Interesting you mention that...
Pete's plugins didn't treat me very well.
The software one wouldn't display the RType Delta pause menu properly. The hardware one wouldn't give me a decent Super Robot Wars F picture no matter what I did.

I really couldn't get a very good 2D game image out of either one.


IMO, Elsimi's(or however it was spelled) was a lot nicer, for what it worked with.
But those last 5 words were the problem.

Thats odd. when did you last try them?

and like I said, most games. Just like how zsnes runs most games without problems.

[Gil_Hamilton]

Give me an emulator that "just works" and I won't ask how it "just works."
I'll be disappointed when I run into something that doesn't, but it's no big deal, there's other games out there.

In that case, wait for MAME/MESS to have decent N64 emulation.

Or for the N64's pSX to show up.
Unless MESS is actually seeing development work.

Give me an emulator that expects me to research and download 3rd-party plugins, the best of which requires YET ANOTHER 3rd-party app, and then has a huge text file full of hacks that STILL doesn't play several games I want(I just checked the hacks file, and probably the first thing I would've tried would've been unplayable)... I'm going to laugh.

Read what I said above. And don't fucking bother with HLE.

So you're saying HLE is inherently kludgy and user-unfriendly?

Then it would seem I AM against HLE.

[Exophase]

He wasn't saying that. Hell, he even admits he uses zsnes most of the time, and that's not close to LLE. >.>

I can see why he'd be frustrated with the different settings for each game deal. PSX emulation was like that for a while, and several n64 games are still in that territory.

I think there's a major misconception as to what "HLE" means, or at least how it was originally meant to be used and what emulator authors meant when they used it.

Low level emulation means emulating a programmable chip one instruction at a time under any circumstances. High level emulation means taking known blocks of instructions and writing routines to emulate the functionality of the entire block, as opposed to the instructions that constitute the block. In fact, in some situations it may not even be known what these constituent instructions are.

Examples of HLE include:

- RSP emulation on the N64. The RSP is a vector coprocessor that is fully programmable - the programs are referred to as "microcode", most likely because they are indexed by function type that make these functional blocks look like CPU instructions. Despite this, the RSP "microcode" is really pretty standard vector coprocessor/DSP fare. Some N64 emulators also HLE some common library routines that would otherwise by emulated on the CPU. This is done for speed, and because it can be less complex than emulating the RSP (which wasn't well understood for some time)

- BIOS emulation in emulators that don't require an original BIOS but emulate games that use BIOS functionality. Here the BIOS functions are emulated at a high level instead of running them through the CPU. This is the case for most GBA emulators and some PS1 ones. This is usually done so that the original BIOS doesn't have to be used, not for speed (although it can help there too)

- The WINE and CXBX emulators emulate entire operating systems at a high level.

- The AdriPSX emulator has used HLE on some common library GTE routines.

- As byuu pointed out, the DSP in SNES carts is emulated at a high level, and other such peripheral micro-controllers often are (at least one or two of the MCUs in the Sega Saturn can be emulated this way)

Calling this approach high level emulation is analogous with high level programming, where a single statement may correspond to several statements in a lower level language (historically, assembly language is considered low level and languages such as C high level, even if it has been pushed down to "medium level." Conversely, LLE emulates ASM instructions and HLE emulates something like functions written in C)

In this thread hardware accelerated implementations of video accelerators in consoles has been referred to as HLE. This is not really the typical usage, and in the past emulator authors (such as ePSXe)'s have insisted that this term not be used to avoid confusion with the above. The reason why this is not considered HLE is because operations are being emulated at the same level as they're visible in the original machine: the operations are basically atomic and don't exist in a very tangible broken down form.

The reason hardware acceleration as a tool for emulation isn't well liked is because it's an approximation. It doesn't give exact results and it can't even provide equivalent functionality sometimes (PS1 and N64 both have unified VRAMs that are hard to map with traditional 3D APIs, allowing for various feedback effects, then there are different kinds of blending modes that might not be available in APIs). It's also possible to enhance the graphics, which often doesn't degrade the appearance by anyone's measure, but purists are against this.

I do believe that with shaders it should be possible to emulate the video subsystems on these platforms accurately (they themselves are rather high level for the most part), although keeping any kind of enhancement as an option could be tricky. It's kind of ironic that an ancient, unprogrammable API such as Glide is what's being used to achieve the best results. Maybe it's just luck. If anything I'd have expected OpenGL to match N64 well since SGI basically developed both of them.

At any rate, aside from some of external chip emulation ZSNES is a thoroughly LLE emulator. At the very least it's no less LLE than BSNES is. Back in the days of these consoles with slow CPUs there was no room to program very much at a high level, or reuse very much code without customization.

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.