Opened 14 years ago

Closed 14 years ago

#4914 closed defect (fixed)

LOOM-PCE: Music stops prematurely

Reported by: eriktorbjorn Owned by: eriktorbjorn
Priority: normal Component: Engine: SCUMM
Version: Keywords:
Cc: Game: Loom

Description

Current ScummVM SVN English PC-Engine version of Loom

In the scene near the beginnig (so there's not much point in including a savegame) where the swan is attacking the elders ("The Guild is under attack!") it starts to play some music, but stops almost immediately. Probably at the next sound effect. I don't think this is the intended behaviour. There used to be a video on YouTube showing the beginning of the game, and the music didn't stop there. (I think that was the Japanese version, but unfortunately the movie has since been removed.)

But I can't figure out how to fix it. From what I can tell, music is started by script-39 and sound effects by script-40, but both are made to stop any other sound before it plays the new one. I experimented with disabling isSoundRunning() for CD audio, but that caused several glitches in the intro alone.

Ticket imported from: #3024173. Ticket imported from: bugs/4914.

Change History (4)

comment:1 by eriktorbjorn, 14 years ago

Summary: [LOOM-PCE] Music stops prematurelyLOOM-PCE: Music stops prematurely

comment:2 by SF/kaminari, 14 years ago

Just to confirm that this is not the intended behaviour. On the PC Engine, the music keeps playing while the PSG notes of the Loom are heard -- until the next scene with the swans flying away from Loom Island, when the music is then replaced by another track (the main theme).

Tested on both Japanese and US versions.

comment:3 by eriktorbjorn, 14 years ago

Owner: set to eriktorbjorn
Resolution: fixed
Status: newclosed

comment:4 by eriktorbjorn, 14 years ago

If I understand hennymcc's explanation of this bug correctly (he's spent a lot more time on this than I have), the scripts get confused because the previous CD track (when the swan breaks through the window) plays for longer than it should. Apparently, the original interpreter hard-coded the lengths for all tracks, but since this is the only one (as far as we know) where this actually makes any noticeable difference.

Based on his suggestion, I'm committing a fix to hard-code the length of that particular track.

Note: See TracTickets for help on using tickets.