Ancurio / mkxp

Free Software implementation of the Ruby Game Scripting System (RGSS)
GNU General Public License v2.0
525 stars 137 forks source link

Sound Effects of the same name shouldn't stack. #125

Open sorlok opened 9 years ago

sorlok commented 9 years ago

If you have a script with the following:

for i in 0..20
  Sound.play_decision
end

...RPG Maker will only play the sound once, while MKXP will "stack" the sound on top of itself. There is either a timeout on sounds with the same filename, or there is handled some other way.

To determine that this is actually how RPG Maker works, I recorded a sound being played once, followed by that sound being played 20 times in both RPG Maker VX and MKXP on Windows. You can clearly see that the waveform is unaffected in RPG Maker, but affected in MKXP. (In Linux, this distortion can actually be heard.)

waveform

For my own purposes, I solved the problem this way: https://github.com/sorlok/mkxp/blob/ld_hacks/src/audio.cpp#L313

Perhaps this isn't really an issue for most games? Stacking sound effects is certainly bad design. Anyway, just thought I'd bring this to your attention.

Ancurio commented 9 years ago

Ah yes, I've dealt with this problem before. Specifically, in a game which displayed each letter of a message box separately and made a typewriter kind of noise for each letter. RMVXA actually ate every 2nd or 3rd of those sounds and made it sound very unnatural, so to be honest, I'm not sure if the behavior in RMVXA is even intentional or just some obscure implementation detail of the sound backend they use.

It certainly wouldn't be wrong to at least introduce some kind of throttling in mkxp, at least for all sound instances played during the same frame. Since you already started experimenting, would you mind finding out what the threshold for RMXP/VXA is before a sound is "swallowed", and if it's related to the current graphics frame at all? (I suspect not)

cremno commented 9 years ago

From the help file(s):

When attempting to play the same SE more than once in a very short period, they will automatically be filtered to prevent choppy playback.

Ancurio commented 9 years ago

Now, to find out what "short period" means :)

sorlok commented 9 years ago

Sure, I'll dig into it. I expect it'll be somewhere around ~50ms, and I agree that it's not likely to be related to the current graphics frame (because I added "sleep" statements to the sample code and then all the sounds played in RMVX).

sorlok commented 9 years ago

Looks like I was way off: it's actually 1ms:

audio_2

I would hazard a guess that they don't even test actual time deltas; they just check if time_in_ms() > last_time_in_ms() for each filename.