Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#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
Keywords: Cc:
Game: Monkey Island 2


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)

monkey2.s03 (30.3 KB ) - added by SF/dfabulich 14 years ago.
Save just before you bring Rapp 2 life

Download all attachments as: .zip

Change History (9)

comment:1 by sev-, 14 years ago

Priority: normallow

comment:2 by sev-, 14 years ago

Yet another iMUSE bug. Lowering priority until we have
someone with time to dig into iMUSE.

comment:3 by eriktorbjorn, 14 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?

by SF/dfabulich, 14 years ago

Attachment: monkey2.s03 added

Save just before you bring Rapp 2 life

comment:4 by SF/dfabulich, 14 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 eriktorbjorn, 14 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 eriktorbjorn, 14 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

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 eriktorbjorn, 13 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 eriktorbjorn, 13 years ago

Owner: set to eriktorbjorn
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.