Opened 21 years ago

Closed 21 years ago

Last modified 21 years ago

#669 closed defect (fixed)

DOTT: Coffee music never stops

Reported by: SF/dfabulich Owned by: SF/jamieson630
Priority: normal Component: Engine: SCUMM
Version: Keywords:
Cc: Game: Day of the Tentacle


Force feed the sleeping Dr. Fred some regular coffee and some cha-cha music will play as he wakes up. This music is supposed to stop once he does; instead, it plays forever, never stopping even if you switch characters.

You can workaround the bug if you hit ESC during that animation, but if you wait for it to finish, it will never end.

A saved game is attached; just use the 'R' coffee on the funnel.

I'm on Win2K with DOTT CD, using ScummVM 0.3.1cvs, Built on Jan 10 2003 12:04:31.

Ticket imported from: #666187. Ticket imported from: bugs/669.

Attachments (2)

tentacle.s09 (58.2 KB ) - added by SF/dfabulich 21 years ago.
Saved game right before bug
tentacle.s11 (63.1 KB ) - added by eriktorbjorn 21 years ago.
Different savegame

Download all attachments as: .zip

Change History (17)

by SF/dfabulich, 21 years ago

Attachment: tentacle.s09 added

Saved game right before bug

comment:1 by fingolfin, 21 years ago

Owner: set to SF/jamieson630

comment:2 by fingolfin, 21 years ago

Jamieson, any idea on this?

comment:3 by SF/yokitori, 21 years ago

It does end but after a really big while (when I played it, I was forced to set the music volume to 0 but after a chile I set it back to normal and the "cha-cha" music disappeared)

comment:4 by eriktorbjorn, 21 years ago

Does this bug still happen? I just tried it, both with the attached savegame and by playing the game from the beginning to this scene, and it worked fine for me.

comment:5 by fingolfin, 21 years ago

I still get the problem with the attached save game.

Erik, you played from the start to this scene, maybe you have a different save game briefly before this scene?

by eriktorbjorn, 21 years ago

Attachment: tentacle.s11 added

Different savegame

comment:6 by eriktorbjorn, 21 years ago

I've attached my savegame. I noticed that I *can* reproduce the problem with both of them, if I choose another sound driver than the AdLib one.

comment:7 by eriktorbjorn, 21 years ago

The same thing happens under Linux, with the ALSA driver but not with the AdLib driver. It's unfortunate that Jamieson's been busy elsewhere lately. I guess I could look into it, but don't hold your breath. This part of the code is mostly black magic to me...

comment:8 by SF/jamieson630, 21 years ago

I'll look into this next Tuesday and try to recreate the problem. If anyone has a chance to investigate sooner, all the better. This sounds like something that should be fixed for the 0.4.0 rollout, but I haven't been keeping track of the 0.4.0 timeline.

comment:9 by eriktorbjorn, 21 years ago

I've looked some more at it. I think I may be on to something, but if so it's quite annoying.

It looks simple enough: It loops the "cha-cha music" for a while, then sets up a "jump hook" to get to the end sequence of it. It waits for the end sequence to end, before restarting the normal background music.

In both the AdLib and the ALSA case, this "skip to the end" is translated, via maybe_jump(), to jump(0, 24, 40), curpos = 11437, topos = 11440. I don't know how curpos and topos are measured, but this seems like a quite short jump ahead to me. Maybe all it has to skip is the "loop from the beginning" instruction.

This is where things start to differ. In the AdLib case, it skips MIDI instructions until curpos is 11472. In the ALSA case, it skips until curpos is 11441. Apparently that isn't quite enough, because it immediately skips to the beginning of the track, i.e. it continues to loop so the "cha-cha music" never stops.

As I said, I don't quite understand how curpos is being calculated here. The base tempo seems to be involved somehow, because if I increase it from 0x4A0000 to 0x4A0600 (in mpu401.h) it will skip until curpos is 11481 instead, and the scene will work just fine.

But "fixing" it that way just seems so wrong to me...

comment:10 by SF/jamieson630, 21 years ago

I've committed what I believe is the fix for this problem. The problem seems to arise from improper handling of the occassional discrepancy between target jump location and actual computed insertion point. The discrepancy is not a bug -- it is expected that the next MIDI event will generally fall somewhere just past the jump point, not directly on it. However, in certain cases the discrepancy was mishandled, causing events just before the jump point to trigger.

This fix takes care of the coffee hand. I also tested the Adlib driver, and nothing changes there. (It always worked, i.e. this didn't break it.) I tested a few other areas of DOTT, but didn't have much time to test thoroughly.

Please test and report back here. S&M in particular needs to be tested, given the complicated loop/jump structure of most of its music. (I think it uses different codes, but just in case....) If bugs arise, back out the change and I'll try to revisit it next week.

comment:11 by fingolfin, 21 years ago

Nice to see you, Jamieson :-) Yeah the coffee problem is gone, remains to test for regressions...

comment:12 by SF/jamieson630, 21 years ago

After looking more closely at the problem, I have submitted a revised fix. The assessment of the problem was correct, but the solution was not. When tracking a MIDI file, two items must be maintained: the byte offset of the current MIDI event that will fire next, and the time at which the next event must fire. The time is measured in "ticks" from the beginning of the track. We track the next event to fire in _song_offset, and the time at which that event should fire in _next_pos. The problem is that when iterating through MIDI events to fire, _next_pos is updated after each event, but _song_offset is only updated once a batch of events are processed. If a jump occurs in the middle of a batch, _next_pos is up to date but _song_offset may be out of date (specifically, it's lagging behind). Thus, the MIDI event to which we jump may actually be chronologically earlier than what we should have jumped to. In the case of the coffee hang, this is the difference between inserting BEFORE or AFTER the loopback command that starts the cha-cha music over.

Again, I only tested this with the cha-cha music under Adlib and Windows drivers. More testing is needed, however I am much more confident about the correctness of this fix than I was with the goofy fix I committed yesterday. (I need to quit analyzing code at the end of 9 hours on my feet.)

comment:13 by eriktorbjorn, 21 years ago

Shouldn't this be closed now? Or are there still problems with it?

comment:14 by SF/jamieson630, 21 years ago

I guess if no regresions have been reported, the fix should be fine. Closing.

comment:15 by SF/jamieson630, 21 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.