I heard...

[Shin_Gouki]

some one saying:
"There are a number of sound problems. Most have to do with noise generation. Listen to Luminaire and Chrono's critical attack in zsnes and compare it to that in bsnes.

Zsnes also has some video issues with Chrono Trigger. Whenever a message box pops up in battle, the screen flashes black for a millisecond. Also, the video output just doesn't seem as smooth as bsnes.

What makes me sad is that zsnes did not use to have these problems. Back in the day sound emulation was near perfect. Then the developers decided to change a lot of code to improve compatibility with a lot of Japanese games that no one had heard of. I think they are trying to emphasize quantity over quality. Bsnes on the other hand, tries to perform cycle-accurate emulation. As a result, you get an experience which features both quality emulation and high-compatibility (at least with the chips that have been emulated so far). On the down side, Bsnes doesn't have many of zsnes's features, such as save states... but since it's open source I might look into implementing that."

Is it true?

What u say?

wbr Shin Gouki

[Deathlike2]

some one saying:
"There are a number of sound problems. Most have to do with noise generation. Listen to Luminaire and Chrono's critical attack in zsnes and compare it to that in bsnes.

The sound core hasn't really changed too much... it needs to be replaced anyways.

Zsnes also has some video issues with Chrono Trigger. Whenever a message box pops up in battle, the screen flashes black for a millisecond. Also, the video output just doesn't seem as smooth as bsnes.

I don't think it's "video output".. it is some timing related bugs at the moment.

What makes me sad is that zsnes did not use to have these problems. Back in the day sound emulation was near perfect. Then the developers decided to change a lot of code to improve compatibility with a lot of Japanese games that no one had heard of. I think they are trying to emphasize quantity over quality. Bsnes on the other hand, tries to perform cycle-accurate emulation. As a result, you get an experience which features both quality emulation and high-compatibility (at least with the chips that have been emulated so far). On the down side, Bsnes doesn't have many of zsnes's features, such as save states... but since it's open source I might look into implementing that."

Sound emulation also consists of hacks back then. Even though some people "prefer the better sound, regardless of the hacks", it breaks other games audio. Compatibility is not a symptom of "what you prefer to fix for your game". Comparing ZSNES to BSNES is never a fair deal since other things in the ZSNES code have to be dealt with such as old code accumulated throughout the years.

Good luck attempting to get savestates in BSNES, that's goal is significantly harder than you will imagine.

Is it true?

What u say?

wbr Shin Gouki

Sometimes, I think you got to realize that ZSNES has a difference audience from BSNES. If you expect perfection, then use a different emulator. Noone will force you to use an emu. We've been saying the same thing for a while.. use the emulator that gives you the best experience for the game.

[Tallgeese]

Psst... Deathlike... ZSNES has a different audience from who...?

[Nach]

some one saying:

I saw that post.

"There are a number of sound problems. Most have to do with noise generation. Listen to Luminaire and Chrono's critical attack in zsnes and compare it to that in bsnes.

Zsnes also has some video issues with Chrono Trigger. Whenever a message box pops up in battle, the screen flashes black for a millisecond. Also, the video output just doesn't seem as smooth as bsnes.

We are working on such issues, we may have improved Chrono Trigger emulation in v1.51 or v1.52, however definitely when the new core is done.

What makes me sad is that zsnes did not use to have these problems. Back in the day sound emulation was near perfect.

Yeah right...
He's probably talking about how ZSNES sounded better in Chrono Trigger back before anyone deciphered BRR decoding and we all just winged it.

Bsnes doesn't have many of zsnes's features, such as save states... but since it's open source I might look into implementing that."

Yeah good luck, due to it's unorthodox style it won't be easy by any stretch of the imagination.

Sometimes, I think you got to realize that ZSNES has a difference audience from ZSNES.

That makes a lot of sense.
Yes I know one of them is supposed to be "place non ZSNES SNES emulator here".

[Deathlike2]

Psst... Deathlike... ZSNES has a different audience from who...?

Bleh, my typos are getting worse.

That makes a lot of sense.
Yes I know one of them is supposed to be "place non ZSNES SNES emulator here".

I know, but my brain is in ZSNES land, I can't help it.

[byuu]

All sound praise should go to anomie, Brad Martin, DMV27 and TRAC. I had very little to do with bsnes' S-DSP core, other than porting anomie's version over to my project.

What makes me sad is that zsnes did not use to have these problems. Back in the day sound emulation was near perfect. Then the developers decided to change a lot of code to improve compatibility with a lot of Japanese games that no one had heard of.

And that's a very good thing. The only way to get 100% compatibility and end the countless flood of bug reports is to do things the right way. And that's where ZSNES is headed, though the transition will undoubtedly be rough for a while. Besides, if you don't care about accuracy, you can always use the older versions of ZSNES with these game hacks in place. Or if you do, well you already know what to use.

Bsnes on the other hand, tries to perform cycle-accurate emulation. As a result, you get an experience which features both quality emulation and high-compatibility (at least with the chips that have been emulated so far). On the down side, Bsnes doesn't have many of zsnes's features, such as save states... but since it's open source I might look into implementing that.

At the cost of massive speed as well, yes. I'd be interested to know who said this, and if this person succeeds in adding savestates. It's totally possible, and indeed mozz did come up with a working method to add savestates to bsnes' one-of-a-kind synchronization system, but it isn't worth the time that could be better spent improving emulation. At least not to me, personally. Some people say they won't touch bsnes without savestates. And really, that's totally fine by me. I don't want such demanding people as my userbase anyway.

Comparing ZSNES to BSNES is never a fair deal since other things in the ZSNES code have to be dealt with such as old code accumulated throughout the years.

There's nothing stopping you guys from completely starting over. I've done it twice now. Further, you've had an eight year head start over me already (though I of course get to start with documentation you guys lacked, nobody from the ZSNES project has ever written any technical docs aside from Nach's cartridge identification doc).

As an aside, I'd be more than willing to help port more x86 assembler code to c code for ZSNES. You know where to get in touch with me, just send some stuff over and I'll peck at it when I have time.

---

I also echo Deathlike's comments and agree completely. While we share the same end goal, we have very different ideals on how to get there. In the mean time, I'm contributing all of my findings to help the ZSNES team out. It's just that some aren't practical for them to implement with the current state of the emulator. All in due time.

[Deathlike2]

Comparing ZSNES to BSNES is never a fair deal since other things in the ZSNES code have to be dealt with such as old code accumulated throughout the years.

There's nothing stopping you guys from completely starting over. I've done it twice now. Further, you've had an eight year head start over me already (though I of course get to start with documentation you guys lacked, nobody from the ZSNES project has ever written any technical docs aside from Nach's cartridge identification doc).

Meh, I think that's not as simple, given the current state of the emulator. Besides, the perrogatives of the previous devs aren't the same as they are now. I don't think you can remove the core hallmark of ZSNES which is the unique GUI. (Porting that would be a crazy goal though).

As an aside, I'd be more than willing to help port more x86 assembler code to c code for ZSNES. You know where to get in touch with me, just send some stuff over and I'll peck at it when I have time.

Well, you know where to look.. there's already a todo list anyways

I also echo Deathlike's comments and agree completely. While we share the same end goal, we have very different ideals on how to get there. In the mean time, I'm contributing all of my findings to help the ZSNES team out. It's just that some aren't practical for them to implement with the current state of the emulator. All in due time.

Yea, eventually it will get there. It's always a matter of time.

[Nach]

I'd be interested to know who said this

The Captain, here: http://forums.ngemu.com/emulation-news- ... 5-0-a.html

Although he said this without knowing anything about bsnes, I don't know if he'll be singing the same tune after he sees the source.

Meh, I think that's not as simple, given the current state of the emulator. Besides, the perrogatives of the previous devs aren't the same as they are now. I don't think you can remove the core hallmark of ZSNES which is the unique GUI. (Porting that would be a crazy goal though).

Hah, just earlier today I was seriously considering writing my own GUI from scratch (for reasons I won't go into to).

[Shin_Gouki]

thx man! i forgot to put my quote source in my first post...
Nice infos all the way! Thc for replying, u talked earlier about the "new" core , ist that a new ZSNES or Audio Core of ZSNES?

wbr Shin Gouki

[Clements]

New audio core.

[FitzRoy]

I took the chance that The Captain or someone else over there knew something about triple-buffering, but it's not likely.

And according to Clements, zsnes had hacks in older versions that made it sound better that have since been removed. Too far back for me.

And just some good example games besides CT:

-star fox: engine sound crackles when it should be smooth
-super castlevania iv: bats and lightning in intro are off, among other things

[pagefault]

We had to release, we hadn't done for over a year. We had stuff that wasn't done and it was buggy. What can I say. We will release more frequently now that we have so called "flushed the buffer". The cause of all the bugs such as in CT and other games are not from japanese games, they are from removal of hacks that were creating artifical results in ZSNES. We have nearly all of these and we plan to keep it that way and fix it the proper way.

byuu: You are a very valuable person to the community and I at least appreciate everything you do for it, and your great emulator. Sometimes I feel I don't even need to power on my SNES to test something because you have it right. anomie and TRAC as well, you guys have put a lot into the scene. I have not written any docs or info, I should but I have no time to so.

The sound will be fixed soon, we have lots of stuff to prepare for that. We know it has problems, just bare with it for the time being.

[byuu]

The only thing I don't understand is why you're only selectively removing some hacks. Either keeping them all or removing them all (or better, making it an option in the GUI somewhere) seems like the most logical choice. Especially if you're keeping hacks for compost heaps like Uniracers; but not for the most popular, like Chrono Trigger.
IIRC, I was told there were currently 12 hacks remaining in ZSNES.

Well, extra documentation is always nice. I've only written a few myself. The ZSNES team really hasn't had any history of working on accuracy, so it's excusable that they wouldn't have written any technical docs. Of course, that's changing now, so perhaps we can get some after all. Myself, I hope to write up the IRQ doc if I can ever find the time. I don't think any publically released emulator gets it right as of now.
Sorry, that comment was meant as a friendly jab back at Deathlike2, as I usually get a "but you had better documentation than us!" response when I mention every other emu had a six year head start over me :P

I know you still insist on using the older libopenspc. However, anomie's core has more recent findings, and DMV27's corrections to it in bsnes make it probably about as accurate as you can get. Possibly short of TRAC's core, which is less portable. As always, you're more than welcome to use bsnes' S-DSP core, if you get permission from anomie first. Not to mention, in this way we can all share our bugfixes and get a perfect core much quicker. We would have a much larger pool of people willing to take a look at issues such as Koushien 2 and Toy Story if this core were used in ZSNES.

[Deathlike2]

The only thing I don't understand is why you're only selectively removing some hacks. Either keeping them all or removing them all (or better, making it an option in the GUI somewhere) seems like the most logical choice. Especially if you're keeping hacks for compost heaps like Uniracers; but not for the most popular, like Chrono Trigger.
IIRC, I was told there were currently 12 hacks remaining in ZSNES.

There are some internal hacks that aren't as easy to remove (SA-1 code for instance would effectively remove support altogether). Most of the hacks removed are those that don't work anymore because of better code...

Well, extra documentation is always nice. I've only written a few myself. The ZSNES team really hasn't had any history of working on accuracy, so it's excusable that they wouldn't have written any technical docs. Of course, that's changing now, so perhaps we can get some after all. Myself, I hope to write up the IRQ doc if I can ever find the time. I don't think any publically released emulator gets it right as of now.
Sorry, that comment was meant as a friendly jab back at Deathlike2, as I usually get a "but you had better documentation than us!" response when I mention every other emu had a six year head start over me

It's amusing anyways. No big deal

I know you still insist on using the older libopenspc. However, anomie's core has more recent findings, and DMV27's corrections to it in bsnes make it probably about as accurate as you can get. Possibly short of TRAC's core, which is less portable. As always, you're more than welcome to use bsnes' S-DSP core, if you get permission from anomie first. Not to mention, in this way we can all share our bugfixes and get a perfect core much quicker. We would have a much larger pool of people willing to take a look at issues such as Koushien 2 and Toy Story if this core were used in ZSNES.

I'd be happy just when the sound core gets replaced period.

[pagefault]

byuu because some hacks break the game completely and it has to be somewhat functional, but the uniracers hack for example was not removed and it should have been. It will be corrected in 1.51. Right now I am waiting on the completion of our new timing system to remove the rest of the hacks because thats all that remains pretty much.