Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#2027 closed defect (fixed)

SAM: Failure to change music at Frog Rock

Reported by: SF/mcewan1 Owned by: eriktorbjorn
Priority: normal Component: Engine: SCUMM
Keywords: Cc:
Game: Sam and Max

Description

At Frog Rock, the music needs to change several times
as actions and events occur. It changes successfully
when the samples are put on the rock, then again as the
sky goes dark. However, it then fails to change a
third time when the flying saucer appears (it's
supposed to play a few dramatic chords then cut to a
fast tempo piece, but instead keeps playing the "sky
goes dark" tune), then finally when the saucer flies
into the horizon it switches correctly to the music for
that event. This is not a fault in the game data, as I
have tested the same CD using the original executable
and it makes the music change successfully.

English CD talkie version of the game, Kixx Software
budget release, Debian(testing) ScummVM package version
0.7.1-1. I think I remember encountering this same bug
at least a year ago in ScummVM, but I could be wrong.

Ticket imported from: #1202071. Ticket imported from: bugs/2027.

Attachments (1)

samnmax.s04 (28.7 KB) - added by SF/mcewan1 14 years ago.
Save game at frog rock, with all necessary inventory items to reproduce the bug.

Download all attachments as: .zip

Change History (11)

Changed 14 years ago by SF/mcewan1

Attachment: samnmax.s04 added

Save game at frog rock, with all necessary inventory items to reproduce the bug.

comment:1 Changed 14 years ago by SF/mcewan1

Summary: Failure to change music at Frog RockSAM: Failure to change music at Frog Rock

comment:2 Changed 14 years ago by eriktorbjorn

Looks like two things happen, musically speaking, around the
time the saucer appears:

It jumps to a different part of the current music. This
might simply be a slightly faster version of the "sky goes
dark" tune. At least it sounds to me as if the music speeds
up slightly.

It starts another piece of music which ScummVM plays as just
one chord.

I wonder if any of them is supposed to be the few dramatic
chords you mention.

comment:3 Changed 14 years ago by eriktorbjorn

My current theory is that neither of the two is relevant to
the bug. The other piece of music probably really just is an
eerie chord, and the jump to a different part of the music
may simply be to get the right timing.

I'm not really familiar with the inner workings of iMUSE,
but from what I understand it's possible to tell it to jump
to a different piece of music "at the first convenient
moment". It then uses SysEx messages embedded in the MIDI
data to inform the player that "this would have been a
convenient moment for doing a particular jump", to which the
player may either ignore or - if it was waiting to do that
jump - act on.

Jumps of type 0 appear to be used for looping a piece of
music over and over again, and as far as I can tell these
particular jumps cannot be ignored. And it looks to me as if
this kind of jump does in fact happen at the wrong moment,
because if I modify the code to ignore the jump in this
particular case (a horrible hack) the music sounds right to me.

But this is a lot of guesswork, and even if it were right I
have no idea at the moment how to fix the problem properly.

comment:4 Changed 14 years ago by eriktorbjorn

Owner: set to SF/jamieson630

comment:5 Changed 14 years ago by eriktorbjorn

Assigning to jamieson630, on the off chance that he'll return.

comment:6 Changed 14 years ago by eriktorbjorn

Disregard most of what I wrote yesterday. There were more
things happening than I first realized, and I was looking at
the wrong ones.

As it turns out, the "jump to a different part of the music"
bit almost certainly *is* significant. The jump happens in
response to the following iMUSE command:

doCommand - 257 (1/1), 53, 0, 1, 10, 4, 400, 1

These values come straight from the script - a soundKludge
opcode - so they should be correct. 53 identify the music
that should be manipulated, and the rest, a[3] through a[7],
specify where to jump. The values are handled like this:

player->jump(a[3] - 1, (a[4] - 1) * 4 + a[5], ((a[6] *
player->getTicksPerBeat()) >> 2) + a[7]);

This is very similar to how we handle the "maybe jump" SysEx
message. There are 480 ticks per beat, so this becomes
jump(0, 40, 48001). The jump() function calls

setTrack(track);
jumpToTick((beat - 1) * TICKS_PER_BEAT + tick);

The track is probably correct, but jumpToTick(66721) fails.

There's a loop point at tick 13360, and I think it's the
music right after that which we want to jump to. Based on
experimentation, to get past that jump we need to jump to at
least tick 13369. That would be jump(0, 28, 409), so
changing the above to

player->jump(a[3] - 1, 2 * (a[4] + a[5]), a[6] + 9 * a[7]);

would fix it in this particular case. But it's not something
I would dare to commit at this time.

(There seems to be some bug in saving the music state. If I
save after putting the sasquatch hair on the rock, but
before putting the powder on it, the music stops shortly
afterwards. Maybe that bug will be easier to figure out...)

comment:7 Changed 14 years ago by eriktorbjorn

I believe the saving of music state has been fixed in CVS
now, so it should be possible to trigger this bug with a
savegame that has been made after putting the hair on the
rock. That should make it a bit less annoying to test it.

comment:8 Changed 14 years ago by eriktorbjorn

I've played through the entire game now. It appears that
this particular jump instruction is mostly used to jump to
the beginning of a new track:

* When going somewhere on the map of the USA.
* When losing, or escaping from, the Wak-A-Rat game.
* When winning the Wak-A-Rat game.
* When Conroy hits Max with his golf club.

In all these cases the four parameters which I believe are
the music position are 2, 1, 0, 0. With values that small it
won't make much difference how I add or multiply them together.

Apart from these cases, I only found two others. The
aforementioned Frog Rock scene, and when leaving the bigfoot
party floor. This could explain the music glitch in bug #888248.

I haven't yet had the time to look further at the bigfoot
party, but I will do so.

comment:9 Changed 14 years ago by eriktorbjorn

I still don't know the correct solution to this, but I have
been doing some more experimenting to see if I could find
something workable by guessing.

Notably the first four cases all sound fine already. That
could mean that the first two parameters are handled
correctly already.

That leaves the last two cases, where it will multiply 300
and 400 respectively with 480. That sounds improbable to me,
so I've decided to swap the last two parameters.

I still don't know if it sounds like the original, but both
cases sound good to me. Feel free to reopen the bug report
if it still sounds wrong to you, but the guy who actually
understood iMUSE hasn't been around for some time now so it
probably won't get any better than this in the near future.

comment:10 Changed 14 years ago by eriktorbjorn

Owner: changed from SF/jamieson630 to eriktorbjorn
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.