Opened 17 years ago

Closed 17 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, 17 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, 17 years ago

Resolution: fixed
Status: newclosed

comment:3 by SF/jamieson630, 17 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.