Opened 16 years ago

Closed 16 years ago

#1132 closed defect (fixed)

SAM: Overlapping music at Bigfoot convention

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

Description

In the main convention floor of the Bigfoot convention,
there are a number of different music tracks that play
(including the "tuning up" track). In some circumstances,
when entering the room all of these tracks seem to start
up at the same time, overlapping each other. When you
exit the room, it sounds like at least one track stops,
but the others continue; the only way to stop them is to
return to the USA map.

This phenomenon was observed with a rather old
savegame, and verified using boot param -b1107 to jump
to the convention center. The problem was not
observed until *after* Sam & Max were made honorary
chieftans and could wander about without the use of
the costume. Whether this is significant is unknown.

Ticket imported from: #785373. Ticket imported from: bugs/1132.

Change History (3)

comment:1 by SF/jamieson630, 16 years ago

Notes from debugging so far, before I forget it all.

Room 52: Convention Center foyer
Room 53: Convention Center main floor
Room 55: Totem Poles exterior

Sound 69: Convention Center foyer
Sounds 70-72: Band music
Sound 73: Band tuning up
Sound 77: Totem Poles

The cause of the overlapping sounds is a deferred startSound
() command being issued by the exit script of one room,
combined with a non-deferred startSound() command being
issued by the entry script of Room 53 (the main floor). The
startSound() command from Room 53 is actually issued by a
script called from the entry script. All of these startSound()
commands are based on a randomly selected number in the
range 70-73.

Both Room 55 (the totem poles) and Room 52 (the foyer)
issue a deferred startSound() only on condition that the new
room being entered is Room 53 (the convention floor).
Furthermoe, Room 52 (the foyer) requires that bitvar[95] ==
0. Presumably this bit indicates whether Sam & Max are
wearing the bigfoot costume, because the overlapping sound
issue does not occur until after Sam & Max have taken off the
costume and been made honorary chiefs.

Room 53 (the convention floor) does its startSound() only if
bitvar[96] == 1. This bit is used to indicate whether the chief
has made his inspiring speech yet. Furthermore, the
startSound() is only issued if the "current music" (see below)
is not already running.

"Current music" is based on var324, and is instantiated with
the random number each time startSound() is called, deferred
or otherwise. In addition, var325 and var326 are "queued
music", and indicate what music to play when the current
music is finished. These are managed in such a way that the
band never plays the same song twice, but always plays at
least two other songs before possibly coming back to that
one.

Since Room 53 checks to see if the "current music" is already
playing, and this results in a getSoundStatus() call to iMuse,
it would seem that getSoundStatus() must check the
ImDeferredCommand list for startSound() commands, in
addition to the old-style cmd_queue. Will test.

comment:2 by SF/jamieson630, 16 years ago

Resolution: fixed
Status: newclosed

comment:3 by SF/jamieson630, 16 years ago

The hypothesis mentioned earlier was correct.
ImDeferredCommands for starting a song must be included in
the check for getSoundStatus(). This has been fixed in CVS.

Alas, since the ImDeferredCommand is issued by the exit
script and immediately checked by the entry script, I had to
add sound command queue processing in between the two, or
else iMuse does not receive the ImDeferredCommand by the
time getSoundStatus() is called. This should not cause any
problems -- we queue far too much stuff that could safely be
executed immediately -- but keep an eye out nonetheless.

Note: See TracTickets for help on using tickets.