Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#669 closed defect (fixed)

DOTT: Coffee music never stops

Reported by: SF/dfabulich Owned by: SF/jamieson630
Priority: normal Component: Engine: SCUMM
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

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 17 years ago.
Saved game right before bug
tentacle.s11 (63.1 KB ) - added by eriktorbjorn 17 years ago.
Different savegame

Download all attachments as: .zip

Change History (17)

by SF/dfabulich, 17 years ago

Attachment: tentacle.s09 added

Saved game right before bug

comment:1 by fingolfin, 17 years ago

Owner: set to SF/jamieson630

comment:2 by fingolfin, 17 years ago

Jamieson, any idea on this?

comment:3 by SF/yokitori, 17 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, 17 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, 17 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, 17 years ago

Attachment: tentacle.s11 added

Different savegame

comment:6 by eriktorbjorn, 17 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, 17 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, 17 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

comment:9 by eriktorbjorn, 17 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, 17 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, 17 years ago

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

comment:12 by SF/jamieson630, 17 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, 17 years ago

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

comment:14 by SF/jamieson630, 17 years ago

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

comment:15 by SF/jamieson630, 17 years ago

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