SCI: Restart sounds in kDoSoundPlay when already playing #2765
When kDoSoundPlay is called on a sound that's already playing, SSCI would restart that sound, but ScummVM has instead just allowed the existing sound to continue. Not many scripts depend on this but a few do and bugs have built up in the tracker. The codepaths for handling samples vs MIDIs are different but they're in the same function and it causes the same kinds of issues.
Fixed by restarting MIDIs:
Fixed by restarting samples:
The change to the MIDI logic brings it in sync with the logic a few lines earlier for whether or not to send init commands. Looking at the history surrounding these lines and how they evolved over a lot of little changes and fixes, it doesn't look like it was ever the specific intent to not restart a sound that's already playing. Little things just got moved around in isolation.
This should also take care of the remaining issues that PR #2128 addresses.
I want to do more testing on this but thought I'd get it out here in case someone can poke holes in it right away. I'm intimidated by sound stuff but this particular behavior is easy to verify. It's also easy to see what happens to the things that depend on it.
The sample change is simpler than it looks in the github diff, essentially it just removes the "if (!_pMixer->isSoundHandleActive(pSnd->hCurrentAud))" check.
Fixes KQ6CD wallflower lockup, bug #10812 Fixes QFG4 door bell puzzle, bug #12105
Great work! This was previously unhandled behavior in ScummVM. Glad it's solving these bugs. I've tested the aforementioned bugs, and the behavior is correct.
We should check if this change fixes any other sound issues from the tracker. It looks like this won't introduce regressions, but the only way to check this would be via testing, which can happen with the daily builds.
Merging this. Thanks again!