#2242 closed defect (fixed)
MI2 VGA: Music as Rapp is instantiating isn't synchronized
| Reported by: | SF/dfabulich | Owned by: | eriktorbjorn |
|---|---|---|---|
| Priority: | low | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Monkey Island 2 |
Description
This bug has been in there for some time, I've just always been forgetting to file it.
As you're using the Ash-2-Life on Rapp Scallion, he changes from ash to human in three stages: first from ash to skeleton, then he gets skin and underwear, and then the rest of his clothes. The music is supposed to make a sound with each transition. But right now, the music makes a sound on the first transition, then nothing on the second, and then a sound on the third, and then finally makes a sound after the animation is complete. This isn't correct with the DOS version of the game.
I've attached a save. Use the Ash-2-Life on the open coffin to see the effect.
I'm using Windows XP, with Monkey 2 VGA Floppy. ScummVM 0.8.0CVS (Oct 11 2005 19:21:40), Features compiled in: Vorbis FLAC MP3 zLib MPEG2.
Ticket imported from: #1324106. Ticket imported from: bugs/2242.
Attachments (1)
Change History (9)
comment:1 by , 19 years ago
| Priority: | normal → low |
|---|
comment:2 by , 19 years ago
comment:3 by , 19 years ago
There aren't any savegames attached to this bug report, so I can't test it myself. But perhaps it's that pitch wheel change I made (and how now modified to not affect the SCUMM engine). Could you try it again with the next ScummVM snapshot?
comment:4 by , 19 years ago
Oops. The save is correctly attached now. This wasn't fixed in ScummVM 0.8.0CVS (Oct 12 2005 17:38:26), but as I mentioned, I think this bug has been in for quite some time; I'd just forgotten to file it. (I'll go back to see if it's in 0.7.1, but I bet it is.)
comment:5 by , 19 years ago
Yeah, I can reproduce the behaviour you describe but it's probably not a regression. I never played it under DOS (since for all practical purposes, I basically fell off the edge of the computer gaming world with the demise of Infocom, and is only now starting to catch up with the 90-ies :-), so I don't know what it used to sound like, but your description makes musical sense to me.
comment:6 by , 19 years ago
I think I see what happens. The animation is handled by script-99, but you'll need a recent version of descumm to disassemble it. (I had to fix a bug in it to do it myself.)
As I understand it, iMUSE allows you to set up "triggers" to run iMUSE commands at certain points (SysEx messages) in the song.
When the animation starts, it sets the tempo of graveyard music (song 102) to 0, effectively pausing it. It does some initial animation, and then starts the three "flourishes" (song 183) that accompany the animation. At the same time, it sets up two triggers to set the tempo of this song to 0.
It animates the first part. At the end of it, it sets the tempo of song 183 back to 128, which is the default.
It animates the second part. At the end of it, it clears any remaining triggers and sets the tempo of song 183 back to 128.
Finally, it animates the third and last part. At the end of it, song 183 should have finished on its own and all that remains to be done is to resume song 102 again.
Now, the idea behind this is probably that on a slow computer it may take too long to run the animation, so it pauses the song to allow the animation to catch up. The problem happens when the animation finishes too quickly. Then it tries to resume the song *before* it has been paused. So the music remains paused during the entire second part of the animation, and doesn't restart until the third part.
So to get the script to run as intended, we'd either need to slow down the animation or speed up the music. Using the --tempo option to set the music speed to 125 fixes it for me, but then the rest of the music feels too fast to me.
I hope I've managed to make sense.
The quick and dirty workaround would be to simply ignore any request to pause song 183 and trust the animation will be able to keep up.
comment:7 by , 18 years ago
After discussing with Fingolfin, I've applied my own patch #1594924 to work around the problem. The pause is now ignored, allowing the three "flourishes" to play uninterrupted. I think we can assume that most platforms running ScummVM are more than fast enough for the animation to keep up with the music here.
comment:8 by , 18 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Yet another iMUSE bug. Lowering priority until we have someone with time to dig into iMUSE.