Current ZSNES Status (moved from romhacking.net)

[pagefault]

The ZSNES story:

Most of our devs are only capable of fixing non emulation related thing. Currently the only people who can emulation relation fixes are me and _Demo_ (when he contributes something), Jonas. He recently redid our mode 7 code to match anomie's formula and is now working on DMA changes based on byuu's research I believe. My job is to work on the CPU and then replace the S-DSP (there you go byuu). So pretty much the project is resting on my shoulders for emulation fixes and I have a day job so it doesn't leave me a lot of time to work on it, so development is slow.

We are trying to do a quality job that hopefully the community can appreciate and enjoy without pointing at us and calling us (we only care about games, we use hidden hacks etc). We are removing all of those, we want to remove the crud that has collected in ZSNES in it's 10 year history and rebuild it fresh with new information. But all this doesn't happen overnight. None of the emulation changes get released in SVN because they have too many side effects with other code that isn't right either. We are trying to be legitimate about this and come out with an accurate emulator (probably not to the level of bsnes, he goes the extra mile and I don't have the resources to do things like that). But you can be assured most things will work properly as they do on the SNES when we are done, byuu has been nice enough to send me tests which don't pass in ZSNES and I try to get ZSNES to pass them by implmenting what has to be done.

The WIP's are something I don't really approve of but some of the developers get excited and they want their feature exposed to the public right away and I may have half-working code in SVN at the time, so it doesn't look good when they run a game. So I would like to stop doing a WIP. When we do a WIP it doesn't really mean the features are stable it just means someone wants to make it public. I don't really feel this is a good idea but my recommendations so far have gone unattented so to speak.

We are also rewriting the debugger which ROM hackers will hopefully enjoy once it's done it's still text based, but using curses so it is portable without any heavy overhead. If anyone has any other suggestions (GTK and Qt aren't really an option) unless you think we should have standalone and Qt builds.

All in all we are trying to improve on the mistakes made in the 10 year history of ZSNES. It was originally made to run games only and as fast as possible. But that is not needed anymore so we need to change how we work on the project and I think we are making good progress so far. We don't really want to release anything until we are sure it's right. You know first impression is everything. I can't promise accuracy on the level of bsnes because byuu cannot be beat at this point he has the resources and the time to do that, but we plan to do our best and pass every test hopefully he can throw at us to at least have another accurate emulator (hopefully).

We are trying to come out with a quality product and respected like it was 10 years ago. But since all the original developers have left the project it's sort been adoped by us and it's sort of like restoring an old car now I guess if you want to put it that way

I will talk to _Demo_ about getting into the domain.

Anyway if you have any other questions let me know.

[creaothceann]

Thread:
http://www.romhacking.net/forum/index.p ... 902.0.html

I will talk to _Demo_ about getting into the domain.

I hope that one gets cleared up. This would solve a lot of the problems.

[Richard C.]

it would be great to have access to the domain so that you could direct it to another server. One that the active devs could easily access would be best . maybe some place like game-host?

[byuu]

My job is to work on the CPU and then replace the S-DSP (there you go byuu).

I don't recall explicitly complaining about ZSNES' S-DSP support. I've been more vocal about S-SMP timing than anything else. I believe the EWJ2 bug lies in S-SMP timing, personally.

So pretty much the project is resting on my shoulders for emulation fixes and I have a day job so it doesn't leave me a lot of time to work on it, so development is slow.

Not to downplay, but to empathize. I also work full-time, and often times I have to take a secondary job as I'm the only income winner where I live currently. It's very difficult to both work full time and come home to work on a hobby. I generally put in 2-3 hours every other day, and I'm fortunate in that at my current job, I can work on my hobbies during downtime to a very limited extent.
On top of that, I have only the occasional direct help of the talented DMV27, and informational help of anomie, Overload and TRAC.

We are trying to do a quality job that hopefully the community can appreciate and enjoy without pointing at us and calling us (we only care about games, we use hidden hacks etc). We are removing all of those, we want to remove the crud that has collected in ZSNES in it's 10 year history and rebuild it fresh with new information.

I tended to be a bit harsher in the past, when our only options were ZSNES and SNES9x. The only accurate alternatives were Super Sleuth (missing sound and speed throttling) and SNEeSe (missing transparency effects). We now have three decent alternatives with varying feature sets, though each are still missing one or two "must have" features.

At any rate, I hope that you don't feel pressured or motivated solely based on what I say or ask for, and I apologize if I annoy you guys with my pickiness. First and foremost, you guys should do what you want to do with the project. Or if you really want to take external feedback, I'd prefer you go with majority opinion rather than just mine.

But all this doesn't happen overnight. None of the emulation changes get released in SVN because they have too many side effects with other code that isn't right either. We are trying to be legitimate about this and come out with an accurate emulator (probably not to the level of bsnes, he goes the extra mile and I don't have the resources to do things like that).

...

All in all we are trying to improve on the mistakes made in the 10 year history of ZSNES. It was originally made to run games only and as fast as possible. But that is not needed anymore so we need to change how we work on the project and I think we are making good progress so far.

...

I can't promise accuracy on the level of bsnes because byuu cannot be beat at this point he has the resources and the time to do that, but we plan to do our best and pass every test hopefully he can throw at us to at least have another accurate emulator (hopefully).

As I've always stated in the past, I think ZSNES is a bad codebase to work from. Emulators written in pure x86 assembly were, back in the day, considered the best. Nowadays, there's simply no need for that. Anyone too cheap to buy a $30 3ghz processor does not deserve to be catered to.

I personally strongly believe ZSNES should start over on a fresh codebase. The world could definitely use an emulator that is barely (if at all) compromised on accuracy, and yet focuses on speed over things transparent to the end user such as the way I tend to implement things exactly as a hardware chip would, even when there are much faster alternatives that provide the same outputs for said given inputs. In a sense, my code is more self documenting for the future, almost to the point of absurdity in some cases.

But starting over is your' guys choice, and you've chosen not to.

But as to the reference of my vast time and resources... again, I spend ~10 hours a week on this, I work alone, and all of my resources include one broken and one working Super UFO 8.3j copier, both totalling ~$200 retail.

So why can I make so much progress so quickly? Because I start over. All the time. I've rewritten my entire emulator from scratch twice now, and I've rewritten entire cores of the emulator more times than I can count. Since my code is all in portable c++, and written using modern OO techniques, this is trivial and takes very little time. I've pulled off an entire CPU rewrite from scratch in ~1 1/2 weeks. There's nothing special about me, and in fact I'm a rather lousy programmer with no formal education in the CS field. Nach and half of #c++ can attest to that fact. You guys are working with raw x86 assembly code, and I know exactly how difficult that is to work with, having directly contributed code to ZSNES on several occasions in the past.

I couldn't imagine how much you would outpace me with 4+ heavily active developers if you weren't held back so much by your legacy codebase.

We are trying to come out with a quality product and respected like it was 10 years ago. But since all the original developers have left the project it's sort been adoped by us and it's sort of like restoring an old car now I guess if you want to put it that way

Yes, we're quite lucky ZSNES has lived on. Nearly all projects, even of ZSNES' fame and magnitude generally don't survive once all founding members of the project have departed.

But it's still a quality product and the number one choice amongst emulation fans. It's more popular by at least two orders of magnitude over my own project. Keep that in mind when you consider the negative things myself or others may say about it from time to time.

To summarize, I apologize again if I'm upsetting you guys or discouraging you in your project, as well as on behalf of anyone else who may be attacking ZSNES based on things I've stated publically in the past. I still believe ZSNES is a great product and I'm personally very appreciative that you're taking the time to fix it up and incorporate the fixes I send to you.

Thanks again for all your hard work.

[kieran_]

Keep up the good work. I enjoy these status posts.

[FitzRoy]

There's no reason to hate or misunderstand what's going on with zsnes. Though writing an emulator is indeed a hobby and some authors have more time/desire whatever to progress their program, it's also about resources. I'm guessing the original zsnes authors knew what kind of sacrifices they were making back in the day to make the emulator playable for people. But do you choose what is necessary for total accuracy in the future, or do you sacrifice that potential for the immediate satisfaction of playing the games on current hardware? Playability generates interest and recruits new talent for further research. In a way, zsnes made bsnes possible... but something tells me that is not the legacy developers want for the program. But that's the law of the emulator jungle, and it's the discrepency between most emulators. There's no animosity in this, it's just how I think things played out. I still use zsnes because it has support for certain things bsnes doesn't have. But if bsnes gets them, will the ultimate goal for zsnes become achieving parity with something that already exists?

As for the boards, there's no reason to let the confused masses continue posting about "xxx not working" over and over and over again without a sticky or something. If there's one thing that zsnes might be criticized for, it's in recognizing too late that most issues were dependent on getting a new core. So instead of working on a new core, you fix the black omen about 7 different times before deciding that it's needed. The WIP changelists are deceptive because 70% of it isn't emulation-related, 10% is battling the old GUI, and the 20% is that which could be broken again at any time without warning. And you can't bookkeep those regressions when you've got hundreds of bugs shifting around, the core is inherently inaccurate, and you've got 3000 games to backtest. It's quicksand.

Well, I've got to go to class right now, but those are my thoughts.

[Stifu]

Accuracy aside, the main problem I have with ZSNES is the GUI, how everything is put together and all... Although many people are nostalgic and like the unique looking menus, I think the mouse trapping, different cursor and everything else are quite annoying, as they don't "blend" 100% right with Windows, if you know what I mean... It's not a problem in fullscreen mode (except when ZSNES crashes, as getting control back can be more annoying than with other programs), but in Windowed mode, I think it'd be much more convenient to have a good old dull looking Windows app...
This wasn't a problem at all back when ZSNES was DOS only, and everything felt good and natural, but to be honest, when the first Windows version of ZSNES got released, I was surprised to see the old DOS look had been preserved...

The GUI doesn't bother me THAT much, but the reason I'm saying that is because byuu mentioned a rewrite, and that it doesn't sound like a bad idea to me, even though it's not going to happen... However, if ZSNES ever got rewritten, it might also be cool to have a skinnable GUI, so everyone can use what they prefer...
Anyway, a rewrite would most likely make you guys feel like you wasted your time for years now (although I'm sure you've learnt a fair load of things through the numerous ZSNES updates)...

Whatever happens and whatever you decide, I'm glad you guys are keeping ZSNES alive. I'm especially looking forward to a new stable core, along with a much improved netplay feature.

[Nach]

So instead of working on a new core, you fix the black omen about 7 different times before deciding that it's needed.

The black omen bug is not related to the core. It's about a bad pointer or an uninitilized variable somewhere in the code. Compiling the same code more than once could have a different output. There really is no way to tell if we fixed it or not. A new core won't neccesarily fix it. Any program could have bugs like this. Even bsnes had issues like this which valgrind uncovered, it could just take years till such a bug is actually noticed.

Some people may think all some of us have been doing this past year is adding pointless features or whatever, but a lot of what we've been doing is fixing issues related to uninitilized variables or certain variables taking a code path which would put it in an invalid state. Such fixes are paramount to everything else in any program. With such bugs something which today might work could easily explode tommorow.

[sweener2001]

Anyone too cheap to buy a $30 3ghz processor does not deserve to be catered to.

while i agree, i disagree. it is not always that easy. motherboard compatibility, blah blah blah. cause the complainers usually have expired hardware. it'll cost more than 30 bucks.

as far as zsnes development, do what you feel to be best for the project. and take your time. i won't mind.

[byuu]

As for the boards, there's no reason to let the confused masses continue posting about "xxx not working" over and over and over again without a sticky or something.

We need to get a volunteer and get a sticky like yours for ZSNES known bugs. At least for me, I find such a list very helpful.
I can't even see the submissions to the bugtracking thing ZSNES set up a while back without registering or something. Screw that.

Any program could have bugs like this. Even bsnes had issues like this which valgrind uncovered, it could just take years till such a bug is actually noticed.

Very true. Depending on how you look at it -- luckily or unluckily for me, all of my variables are defined in .data, and not .bss, so they are all initialized to zero intrinsically by the compiler if no default assignment variable is given.

I kind of wish there were a compiler switch that would flood all variables not explicitly declared with a static initialization value with random values at each startup instead. It would make finding and fixing these bugs much easier.
I've no interest in learning how to use Valgrind, so that's sort of out of the question. But I always appreciate Valgrind logs and try and fix what I can in them.

Some people may think all some of us have been doing this past year is adding pointless features or whatever, but a lot of what we've been doing is fixing issues related to uninitilized variables or certain variables taking a code path which would put it in an invalid state.

On the contrary, I think ZSNES is mostly moving in a very positive direction. My only recent complaints were the Uniracers fix (which pagefault conceded on), and writing the new CPU core in assembler again, instead of taking the opportunity to port part of the core to C; which would have made it much easier to add in bus synchronization if you ever decided to go that far. You may not even be thinking about it now, but I'll bet you weren't interested in a cycle core two years ago either, right?

But I still believe a rewrite would prove far more fruitful. True, not right away. It'd take a good 12-36 months to rewrite all of the various features in ZSNES with four or so active developers. But if you're planning on sticking with ZSNES for more than 3 years from now, I think it would be for the best. Otherwise you may find yourself with some much heavier competition, and not just from me: all Overload needs is audio output and Super Sleuth will be my primary emulator for gaming, and TRAC just needs some GUI polishings and special chip support. The speed differences will become less and less important as time goes on (though again, an emulator that leverages both speed and accuracy would be a very good thing indeed -- SNEeSe leads the pack here presently).

[pagefault]

I don't think you understand byuu, this isn't a competition. We don't consider it one, we will work on ZSNES at our own speed and impove it as necessary as our users request. Porting the CPU core to C would be a pointless endevour for us, we aren't trying to be portable to other platforms than x86 at this point so we are going for speed. There is no reason we cannot achieve decent accuracy using an assembly based engine. There is no pressure on my part because I am 100% confident in the code I am writing. It is good code and it will perform well.

I have no problem if people want to use some other program, thats their choice. Just because another emulator offers something else that appeals to the user doesn't make it competition, it's not like we are trying to prove or make money off this. We see it only as a hobby.

I think everyone will be very pleased with our release that will be coming out mid 2007, most of all emulation code will have been rewritten and it will probably be called ZSNES 2.0 because so much as changed. In the mean time we are considering a 1.50 release with the current code base because of the people getting sick of WIP's. Some people are content the way ZSNES is right now and just want a release so they can distribute it.

We just have a lot of stuff to clean up in the code before this happens. If you don't like something in ZSNES you don't have to use it, but we are far from giving up and calling it quits, we have lots of good stuff coming I think will satisfy the critics of our project.

[FitzRoy]

The black omen bug is not related to the core.

Admittedly I know nothing about code and was being presumptious, but there are undoubtedly a lot of bugs that need the accuracy of a better core to "properly" work. Byuu talks a lot about "edge cases," and I remember one bug not too long ago that byuu said serendipitously worked in zsnes because its timing was so far off. In a way, now you're dealing with bugs in the emu that aren't even showing themselves, and that's got to be confusing when your initial approach was game compatibility and not hardware accuracy with the result of game compatibility.

We need to get a volunteer and get a sticky like yours for ZSNES known bugs. At least for me, I find such a list very helpful.

Well, what I meant when I said that is to scrap the verified bug section (which is pretty much dead), and to offer some kind of disclaimer about not posting game bugs until the new core is in. Right now, I think a known buglist for zsnes would be a bad idea. Too many initial bugs for backtesting and a new core on the horizon.

we have lots of good stuff coming I think will satisfy the critics of our project.

That's good news. One thing that zsnes will always have going for it is huge name recognition, and 2.0 will meet with much fanfare. This is a huge obstacle for byuu and I'm frustrated for him, because many people are still oblivious to bsnes (or anything other than zsnes: see sig). I see a lot of grief in the zsnes bug reports forums, but it would be discourteous of me to recommend bsnes outright for zsnes' problem games.

[byuu]

I don't think you understand byuu, this isn't a competition. We don't consider it one, we will work on ZSNES at our own speed and impove it as necessary as our users request.

I don't remember saying it was one. And again for the record, we're definitely not in competition. If that were the case, I'd be closed source and I wouldn't be sharing every single finding of mine with you guys free of charge. I absolutely want to help you guys, to the point where I'd even like to donate source code. I've always said you guys are free to use any of bsnes' source code for ZSNES. You don't even have to ask.

The way I do think of it, however, is friendly competition. Huge difference. There's no need for any of us to outdo another, as we're all working together toward the same goal. However, I can honestly say that I believe all of us have been motivated to make progress on our emulators due to the presence of alternatives, regardless if we admit it or not. And that's a good thing, for everyone. You wouldn't want just one OS, you wouldn't want just one anything. As that always, always leads to stagnation (see: IE6->IE7).
I see stagnation even in my own work with Der Langrisser's English translation.

Porting the CPU core to C would be a pointless endevour for us, we aren't trying to be portable to other platforms than x86 at this point so we are going for speed. There is no reason we cannot achieve decent accuracy using an assembly based engine. There is no pressure on my part because I am 100% confident in the code I am writing. It is good code and it will perform well.

It's your source so that's definitely your right. The benefits of C speak for themselves, though. Other people can read the code and fix mistakes, additions are far easier to add, the code is portable not just for ZSNES but for any emulators that wanted to use the core in the future, there's no guarantee x86 code will run forever (perhaps one day 32-bit apps will be as 16-bit apps are today, maybe worse) and the speed benefits of an x86 core are quickly diminishing. When Moore's law (or whatever) pushes emulator requirements from ~1% for ZSNES to ~10-15% for the slowest competitor, people aren't going to care anymore about speed.
I have no doubt that your work is top notch, however. I've seen your programming work firsthand and you're definitely a better programmer than I.

That's good news. One thing that zsnes will always have going for it is huge name recognition, and 2.0 will meet with much fanfare. This is a huge obstacle for byuu and I'm frustrated for him, because many people are still oblivious to bsnes (or anything other than zsnes: see sig). I see a lot of grief in the zsnes bug reports forums, but it would be discourteous of me to recommend bsnes outright for zsnes' problem games.

If pagefault and co truly aren't concerned about maintaining ZSNES' popularity position and truly view this as complete non-competition, then I suspect it will suffer the same fate of certain NES emulators of the past -- though probably not for another five to ten years. Overload really is one feature away from having a complete alternative to ZSNES, that's useable right now. However, given the recent cycle accurate CPU core pagefault is working on, I don't entirely believe there is not at least friendly competition here still. Which again, I view as strictly a positive thing. Although I wish people listening to our (myself mostly) banter about accuracy would've taken a friendlier approach to convincing pagefault that a cycle core would be a very good thing for ZSNES.

As far as recommending my work, nah. Recommend all of the other emulators that run the game. Kind of rude in that this is ZSNES' forum and not a general SNES emulation forum, however.

[Nightcrawler]

The new CPU core rewrite is in assembly? That's not a problem in itself, BUT I hope to hell you comment the crap out of it at the very least. Otherwise, it's no better than the current ZSNES assembly core as far as getting other people to help and contribute. We've see how many people have wanted to contribute to the core in recent years...

ZSNES can't ride on one person's shoulders forever. If you don't do something to make it easier for other people to help on the workhorse of the emulator, it will just die off when you lose interest. And you HAVE lost interest for awhile before...

I agree with most of the points that have been made here otherwise.


P.S. It would be nice if you FINALLY disallowed writes to VRAM during vblank. This has caused alot of broken code to be written by homebrew people and ROMhackers over the years.

[Nach]

Very true. Depending on how you look at it -- luckily or unluckily for me, all of my variables are defined in .data, and not .bss, so they are all initialized to zero intrinsically by the compiler if no default assignment variable is given.

I kind of wish there were a compiler switch that would flood all variables not explicitly declared with a static initialization value with random values at each startup instead. It would make finding and fixing these bugs much easier.

OpenBSD has done a ton of work in this area. They have special parameters in their GCC patch, as well as stuff going on in the OS itself to randomize all sorts of things when working with a program. Stuff like random values for each .bss, randomly moving data and code around in memory on load, and all sorts of other things. http://openbsd.org/security.html see "New Technologies".

Overload really is one feature away from having a complete alternative to ZSNES, that's useable right now.

Perhaps in your mind. However not everyone will agree with you.
There are those that want to play Top Gear 3000. Those that don't use Windows. People who enjoy ripping SPCs to listen to later, or to make movies of themselves. Nothing is a complete alternative to something else unless it does a minimum of everything the other does.

[byuu]

OpenBSD has done a ton of work in this area.

Yeah, I remember you mentioning something like that in the past. Thanks for the link. I should really try and install it sometime. So Theo still hasn't written his own compiler yet? :)

Perhaps in your mind. However not everyone will agree with you.
There are those that want to play Top Gear 3000. Those that don't use Windows. People who enjoy ripping SPCs to listen to later, or to make movies of themselves.

While I agree it isn't a 1:1 replacement, choosing your favorite emulator is an evaluation of many factors. Super Sleuth has most features an average user will need: speed, accuracy, compatibility, SFX, SA1, DSP-1, savestates and a debugger.
And just like everyone has to use a secondary emulator to play all the games ZSNES has bugs with or just plain doesn't run, likewise they could just as easily make ZSNES the backup for TG3k.

Realistically, nearly all SPCs that could be ripped have been, and they're incredibly small to distribute. Movies... I really don't see a lot of people using this. Definitely a cool feature, and definitely desirable, but I think those interested in accuracy would rather have that than movies.

I don't honestly think Super Sleuth will overtake ZSNES in popularity, but just saying that we do have some strong friendly competition in the SNES scene. This is all a hobby, and it's a fun one. But one can't rest on their laurels forever and must change with the time if they want to stay the best, and x86 assembly hardcoding has been out for a few years now :)

[Nach]

OpenBSD has done a ton of work in this area.

Yeah, I remember you mentioning something like that in the past. Thanks for the link. I should really try and install it sometime. So Theo still hasn't written his own compiler yet?

NP.
Last I heard Theo was recruiting people to write a C compiler, and there was a rumor that the next hackathon will start that project off. Perhaps I should search their site more to find some concrete info.

While I agree it isn't a 1:1 replacement, choosing your favorite emulator is an evaluation of many factors. Super Sleuth has most features an average user will need: speed, accuracy, compatibility, SFX, SA1, DSP-1, savestates and a debugger.

Average users need a debugger?
I think those that use the debugger is less than 1% for any emulator for the masses. Perhaps in a case like bsnes where currently it only enjoys a niche audience that number might be closer to 5%.

Realistically, nearly all SPCs that could be ripped have been, and they're incredibly small to distribute.

Doesn't mean people want to go around looking for them. Whenever I'm playing an SNES game and come across a BGM I like, I hit rewind to the start of it, then proceed to dump it.
I'm not going to randomely download packs online hoping I come across something I like, nor am I going to go hunt around for something when I have it right there in front of me. I have a few hundred SPCs which I dumped myself. The only ones I have which I haven't dumped was a ToP set by grinvader since he went through the effort to dump it and it's a bit tricky.

Movies... I really don't see a lot of people using this.

I haver >1000 movies made with ZSNES.
Back when movies where added to ZSNES ~7 years ago I thought it was the coolest thing ever. I always wanted to capture some of my best performances.
For those that know about it, I'm sure many people use it, especially if they like showing some exciting sequences off to friends and family.
One thing which kept me hooked on Nesticle for a while was being able to record and watch movies I made.

Definitely a cool feature, and definitely desirable, but I think those interested in accuracy would rather have that than movies.

It might be shocking but the masses really couldn't care less about accuracy. If they get all their games playing percievably flawlessly the rest means nothing to them.

Your average user will pick the app which seems easier to use, or the one with more gimicks they may make use of if there is practically no difference in what they use it for.

[byuu]

Average users need a debugger?

Nah. That one was more for me, heh.

It might be shocking but the masses really couldn't care less about accuracy. If they get all their games playing percievably flawlessly the rest means nothing to them.

Sadly, I'm well aware of this. People wouldn't be using emulators period if they truly cared about accuracy. Because none of us hold a candle to an actual console yet when even basic hardware math isn't emulated properly, and our idea of PPU emulation is scanline renderers.

Still, I can dream. I'm hopeful the SNES emulation scene will become like the NES emulation scene where inaccurate emulators become the joke that is NESticle, and the dominant emulators are Nestopia and Nintendulator.

Your average user will pick the app which seems easier to use, or the one with more gimicks they may make use of if there is practically no difference in what they use it for.

I think there's a little more to it than that. I believe the first app most people use, they tend to stick with forever. You see people using 3-4 year old copies of ZSNES all the time, right? They've no reason to upgrade, even to a newer version of ZSNES. Same with all the people running Win98, Photoshop 7 (myself included there), etc.
ZSNES has a huge advantage there, having been around for 8+ years now.

But as far as easy to use: yes, ZSNES is quite easy to use, but the GUI is definitely far from native. So you lose some points there. Consistency is great, IMO, but not many people really use multiple operating systems, either.

[Nach]

Because none of us hold a candle to an actual console yet when even basic hardware math isn't emulated properly, and our idea of PPU emulation is scanline renderers.

Right, but I'd still prefer to use an emulator (if it emulated the game percievablly well). As nice as the real console is, I'd rather use one peice of hardware for it all, get a filtered picture, be able to save and load state.
The only case where I personally may want to use the original is when it's portable and I don't want to lug around a laptop, hence I still use my Gameboy time to time.

Your average user will pick the app which seems easier to use, or the one with more gimicks they may make use of if there is practically no difference in what they use it for.

I think there's a little more to it than that. I believe the first app most people use, they tend to stick with forever.

Not so sure if that's always true. Personally, I know it's rarely true. I started with SNEmul as my SNES emulator, but I just didn't like it. Then I tried ZSNES and Snes9x a while later, and chose ZSNES as my SNES emulator of choice.
For Gameboy, I can't even remember which one I started with, but I kept on trying every new one that came out each month, I haven't been satisfied with a single one of them. Even VBA upsets me at times, although I think it may be the best of the current options. If you tell me there is something better than VBA, I'll happily try it.
For people like me though, it sometimes is hard to get me interested in something else, since you'll have to do more than a standard set of functionality since I actively make use of advanced features.

But as far as easy to use: yes, ZSNES is quite easy to use, but the GUI is definitely far from native. So you lose some points there. Consistency is great, IMO, but not many people really use multiple operating systems, either.

I wasn't refering to ZSNES per se. I just know based on tons and tons of ZSNES vs. Snes9x threads that people decide solely on GUI. And contrary to what you're saying people have said we gain points for not being native.

And personally I run tons of OSs. I ran 10 different OSs this past Sunday while working on expanding the battery feature.

[byuu]

A lot of your feedback there are personal preferences again, and we were talking about the majority. The majority consists of 96%+ Windows-only users, unfortunately. And the majority of Windows users apparently can barely use the native windows file open dialog, let alone a custom one that separates folders from files.

The GUI debate will probably always be there. From what I've read on all forums, it seems to be about 60% prefer native to 40% prefer ZSNES; though well over 60% use ZSNES anyway due to all of the other benefits of ZSNES (speed, compatibility, features, etc). Of course, this is all perception. A truly unbiased poll of thousands of users on a site other than zsnes.com or snes9x.com would be needed to get accurate numbers. I also think a skinnable GUI would give you major points against those who prefer an OS-native approach. A powerful enough skinning engine and you could get near perfect simulation of many major OSes with only a single, portable library. Very appealing, actually.

To go into personal preferences again, I like all of my apps to look the same on the OS I'm on. This was a huge selling point for XFCE. I use gedit, xchat, gaim and firefox as pretty much my only addon software. So XFCE + all but firefox being GTK+ already, everything looks the same. And I really appreciate that. Of course, all GTK+ apps look like ass on Windows. If everything I used were QT, it would be even nicer.
But I don't mind the ZSNES GUI, it's very functional. My only two minor concerns are the mouse catching issues, and the tiiiiiny tiiiiiny blocky font.

[xamenus]

Check out the ratings: http://www.emulator-zone.com/doc.php/snes/

ZSNES wins by a landslide. Based on this poll, there would likely be many, many people who would be upset if ZSNES were discontinued, despite it not being as accurate as the others.

It's nice that Nestopia is catching on fast in the NES emulation scene. I think SNES emulators would do well to model after its design.

Other than that, I agree with pagefault's and Nightcrawler's stances on the WIPs, ZSNES websites needing better organization, etc. I'm glad that this discussion was finally brought up.

[byuu]

True, it's definitely the most popular. We already knew that. What we don't know is how many people would prefer a native Windows-style interface versus how many people use ZSNES for other reasons (speed, features, compatibility, etc). Also, the fact that SNem received 144 10.0 votes seriously brings that poll into suspect (6.9 to SNEeSe' 7.2??). Sorry, tommowalker :/

[Stifu]

Besides, that page is not "fair"... The fact ZSNES is at the top of that page, as well as each emulator description more than likely influenced the visitors and the votes...
Somehow "One of the best Super Nintendo emulators available." seems a little more attractive than plain "SNES Emulator".

[Deathlike2]

Well, it shows popularity, but it probably doesn't factor in that SNEeSe is Windows+DOS IIRC, and that it now renders w/transparancies (16-bit) and has the best audio (at least in terms of having it first). Maybe it's just me, but the activity in the Snes9x forums doesn't compare to the ZSNES forums.. but what do I know?

[Firon]

The ZSNES story:
None of the emulation changes get released in SVN because they have too many side effects with other code that isn't right either. We are trying to be legitimate about this and come out with an accurate emulator (probably not to the level of bsnes, he goes the extra mile and I don't have the resources to do things like that).

Couldn't you technically have a "branch" for emulation-related changes that may break a ton of things, and then a trunk for the main code (as it is now) without said emulation fixes?
That way you can add your fixes and possibly have people test them if necessary, while still allow the WIP people to build a working ZSNES build from the trunk.