#2027 closed defect (fixed)
SAM: Failure to change music at Frog Rock
| Reported by: | SF/mcewan1 | Owned by: | eriktorbjorn |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | 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)
Change History (11)
by , 20 years ago
| Attachment: | samnmax.s04 added |
|---|
comment:1 by , 20 years ago
| Summary: | Failure to change music at Frog Rock → SAM: Failure to change music at Frog Rock |
|---|
comment:2 by , 20 years ago
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 by , 20 years ago
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 by , 20 years ago
| Owner: | set to |
|---|
comment:6 by , 20 years ago
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 by , 20 years ago
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 by , 20 years ago
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 by , 19 years ago
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 by , 19 years ago
| Owner: | changed from to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Save game at frog rock, with all necessary inventory items to reproduce the bug.