Opened 14 years ago

Closed 14 years ago

Last modified 19 months ago

#8584 closed patch

Workaround for bug #1324106

Reported by: eriktorbjorn Owned by: eriktorbjorn
Priority: normal Component: Engine: SCUMM
Keywords: Cc:
Game: Monkey Island 2


This patch works around the music synchronization glitch described in bug #1324106 ("MI2 VGA: Music as Rapp is instantiating isn't synchronized") by simply ignoring any triggered request to pause the "three flourishes" music.

But perhaps this isn't the right way of doing it. After all, the underlying problem is that the animation finishes too quickly compared to the playback speed of the music...

Ticket imported from: #1594924. Ticket imported from: patches/689.

Attachments (1)

rapp-workaround.diff (1.5 KB ) - added by eriktorbjorn 14 years ago.
Patch against current SVN

Download all attachments as: .zip

Change History (8)

by eriktorbjorn, 14 years ago

Attachment: rapp-workaround.diff added

Patch against current SVN

comment:1 by eriktorbjorn, 14 years ago

Debugging hints:

The scene is handled by script-99

Boot param 900 will put you near the graveyard with all the stuff you need.

comment:2 by fingolfin, 14 years ago

Well, if the patch solves the problem for you, sounds OK (I didn't try it myself, though).

Of course, one has to wonder why the problem occurs for us in the first place. Was it simply sloppy coding in the scripts? If so, does it also occur when running MI2 with the original engine on fast machines? Or are we doing something wrong?

comment:3 by eriktorbjorn, 14 years ago

Well, iMUSE is still rather magical to me, but this is probably the tricky part of the script:

[022D] (1C) startSound(183) [022F] (4C) soundKludge([-1]) [0234] (4C) soundKludge([270,183,1]) [023F] (4C) soundKludge([271,262,183,0]) [024D] (4C) soundKludge([271,-1]) [0255] (4C) soundKludge([270,183,1]) [0260] (4C) soundKludge([271,262,183,0]) [026E] (4C) soundKludge([271,-1]) [0276] (4C) soundKludge([-1])

This gibberish means that we set up a trigger with ID 1 for song 183 (270, 183, 1). The trigger command is to set the speed of song 183 to 0, effectively pausing it (271, 262, 183, 0). We do this twice. Song 183 is the three flourishes, one for each stage of the Ash2Life transformation. The music data contains markers to set off these two triggers right before the second and third flourish respectively.

The animation consists of drawing a series of frames, each separated by a breakHere() opcode. After that, it does a series of breakHere() to delay further, and then

[0318] (4C) soundKludge([262,183,128]) [0323] (4C) soundKludge([-1])

This resets the tempo to 128, effectively unpausing the music. After the last flourish, it also clears the queue, removing any left-over triggers.

I have no way of testing what happens with the original interpreter on a fast machine. What happens in ScummVM is that the animation finishes too quickly: The script then unpauses the music *before* the trigger that pauses it is set off. To have the pause/unpause happen in the correct order, we either need to speed up the music or slow down the animation.

What the patch does is to ignore the triggered pause commands, forcing the flourishes to play uninterrupted.

I hope that made sense. It's a bit too late at night to unravel the mysteries of iMUSE. :-)

comment:4 by fingolfin, 14 years ago

Thanks for your detailed explanation. But I still am wondering *why* the animation runs too fast. I thought that all animations in SCUMM games are, at least to a degree, coupled to the SCUMM internal timers (simply because we limit how often the main loop is run per second). As such, it seems odd that suddenly the animation should run "too fast". I.e. maybe there is a deeper reason behind this issue? Maybe we need to throttle down the main loop a bit?

Anyway, I have no fundamental objections, feel free to add this patch.

comment:5 by eriktorbjorn, 14 years ago

Owner: set to eriktorbjorn
Status: newclosed

comment:6 by eriktorbjorn, 14 years ago

I don't know why the timing is off (only by a few tenths of a second, it seems), or why there appears to be two queued events, but only one trigger embedded in the music. The explanation I wrote is, of course, just my best guess. But it *should* be safe, so since you don't have any objections I'm applying it.

comment:7 by digitall, 19 months ago

Component: Engine: SCUMM
Game: Monkey Island 2
Note: See TracTickets for help on using tickets.