Language…
7 users online: ezdeez85, GRIMMKIN,  Nanako,  Ringo,  Segment1Zone2,  Telinc1, toady - Guests: 238 - Bots: 289
Users: 64,795 (2,375 active)
Latest user: mathew

Attention music porters.

With the potential of a new ZSNES (which will likely emulate the audio of ROMs more accurately than previous builds) soon, smkdan spotted a rather major flaw which is apparent in 99% of ports which use echo commands. Several Japanese TXTs contain this error as well.

The command for echo is $F1 $XX $YY $ZZ. Most people will often set the $XX here higher than $04, in which I was recently informed crashes the game on accurate emulators. Here is smkdan's breakdown of why:

Originally posted by smkdan
The APU setup has 64KB of RAM (ARAM) that is shared between music data, sample data, SPC code and the echo buffer. The echo buffer is used whenever echo is enabled in a piece of music, it's constantly written to as audio is generated. SMW originally allocated only 8KB for this, directly after the echo buffer comes the sample data. 8KB only allows for a echo length/echo delay setting of 4 at most, you can use lower settings with no problem, but 5 or higher means the sample data gets corrupted because the echo buffer is now greater than 8KB i.e. it's 'overflowing' from the original 8KB area into the sample data and sample data is lost. The result is no audio at all beyond a few pops and clicks.

Snes9x and ZSNES don't emulate the audio side of things properly which is why you don't hear the consequences on these. bsnes DOES emulate it properly and if the audio in a hack dies in bsnes, then it's probably becuase the custom music set the echo delay too long. ZSNES 2.0 WILL emulate it properly and all hacks that don't follow this rule will be running deaf.


This seems to be a rather major bug with many, many ports on SMWC and elsewhere.

Therefore, from here on out, all songs which contain a value greater than $04 in $XX will be rejected. This will last until I can get ahold of Romi (or if anyone is on the IRC very early in the morning EST, I would appreciate it if you could contact him). Also, if you have recently ported a track which contains a value greater than $04, please fix it.

Thanks for your understanding.
Hm, this is important indeed. I'm glad to hear of this, and will take note for both ported songs as well as those downloaded.

As for romi, are you hoping for an update of his addmusic to output it as an error?

World Community Grid: Thread | Team
 
I'm glad guidelines are being put into terms of accuracy. I'm not familiar with music porting in Super Mario World, but it's good to see that accuracy is an important deal for SMW Central. (And I'm happy to hear about the makers of ZSNES caring about that too, now.)
--------> Don't follow "Find Roy's Dignity", my hack. Because it's pretty outdated. <--------
Ulti: I'm hoping so. As it is now, it inserts perfectly and doesn't even inform you that it is an error.
So basically we're going to have to recommend to people to have ZSNES 1.xx for games released before 2010 and ZSNES 2.x for games released after, otherwise we'll run into music compatibility issues?
Well, hopefully not. What I am planning on doing is going through most of the tracks in the music section and making a note of the ones which have this particular error. Since 95% of the authors who made the music are still active, it's simply a matter of PM'ing them and getting them to fix the error.

Once that is resolved, things should work as expected.
That doesn't really address what FirePhoenix was talking about. He meant that hacks that have been released using those tracks will crash ZSNES 2.x, so it should be recommended to use 1.x for them.
Ah yes, my bad.

Yeah. We'll have no other choice but to do that.
Well, replacing the hacks would be tough too, but still possible. A warning in the meantime of course is good.

Has anyone tried conacying the developers of ZSNES? Perfects some of our programmers and some of theirs can work together to work a fix patch for this for ROMhacks. Or hell, Maybe even a ROMhack specific version of ZSNES that stretches the limits of SNES emulation.

[/crazy dream]
I made a standalone game once, look for Seabug Stampede on Google Play.
Well in all honesty it's nice to move onto better things for the sake of accuracy but this was never a huge issue before. For the sake of not going through this major hassle, I don't see why we can't just tell people on smwc to use the older version of ZSNES and keep that version in the tools section. We're all here as SMW hackers and we know what we're looking for to hack. Even the n00bs could be enlightened on the situation. Either that or we can put a label the custom music section telling that they won't be compatible with ZSNES 2 like how the custom block section tells if a block is compatible with BTSD or not. That way if they decide they want custom music they would know ahead of time. This is just the way I see it personally.
I think a post layout goes here somewhere...
Whoa! I never thought that something like that could've been a problem! o.o;
Personally though, I don't think music ports should be rejected because of that. Maybe instead we should put something in the description that says: "ZSNES 2.0 Compatible?: Yes/No". I mean, all emulators play hacks a bit different than others. We don't just go around removing hacks because they don't work on certain emulators now do we?
Originally posted by forxen
Whoa! I never thought that something like that could've been a problem! o.o;
Personally though, I don't think music ports should be rejected because of that. Maybe instead we should put something in the description that says: "ZSNES 2.0 Compatible?: Yes/No". I mean, all emulators play hacks a bit different than others. We don't just go around removing hacks because they don't work on certain emulators now do we?


That could work, but unlike N-SPC and Sample banks, it affects the hack player, not the hack maker. I think this is the reason for the change.
Originally posted by Norepad
That could work, but unlike N-SPC and Sample banks, it affects the hack player, not the hack maker. I think this is the reason for the change.

And then either the hack maker or tester could simply warn the player that it's not compatible with ZSNES 2.0. Personally, I just really don't want new porting requirements simply because of emulator compatibility issues. If a more "accurate" version of an existing emulator is supposed to cause more glitches than the last version, I'd personally stick with ZSNES 1.51 rather than 2.0.
Accuracy =/= less glitches

Not to mention that music is much easier to resubmit than a hack is, easier to fix, and it's not even a tough requirement.

World Community Grid: Thread | Team
 
Not necessarily because some people take pride in music such as Jimmy and myself and we want it to be as good as possible and to do that we need to exceed these "limits" to get that, such as some hackers make ASM super amazing etc...
I think a post layout goes here somewhere...
Originally posted by Santacus Clausimus
Not to mention that music is much easier to resubmit than a hack is, easier to fix, and it's not even a tough requirement.


Ulti, some people use $F1 $50+. Try removing $4C from that value and listen to the song. It just doesn't get the needed echo across.
There should be absolutely nothing actively hosted on this site that has zero chance of working on a real SNES and in turn, has no chance on working with proper emulators. If you want music that only works with a fantasy machine that a grossly outdated emulator actually emulates (i.e. not a SNES) then that's your business. It doesn't belong on a site with any sort of standards regarding submissions though.

Originally posted by Caracc
Or hell, Maybe even a ROMhack specific version of ZSNES that stretches the limits of SNES emulation.


This is the polar opposite of what literally every emulator author wants. They want to move *away* from emulators that let romhackers get away with ridiculous things that only a fantasy SNES (i.e. not doing its job as an emulator) would be able to do.
I'm sorry to those who are discouraged by this. There is nothing we can do about it. If change is occurring on the emulator front, it would be nice if changes would occur within the actual files themselves. As smkdan stated, there are people who only use emulators such as BSNES (which are extremely accurate), and if we're hosting a bunch of files which will fail on said emulator, it just seems stupid.

Obviously, this error wasn't caught until very recently, or else we all could have worked around it.
Correct me if I'm wrong but, isn't SMW the one not able to handle the echo? I agree with you that we should strive for hacks that can actually be run on an actual SNES, but you're asking for us to basically KILL the echo command. SNN pointed it out, almost every song with an echo uses a value greater than 04. Most echoes with such a low value are barely audible. Though I agree, you're sounding very dogmatic and I feel will be asked of you SMKD, with the assertion you made.

Why should we should kill our quality for your ideal hacking world?