#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 |
Description
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)
Change History (17)
by , 22 years ago
| Attachment: | tentacle.s09 added |
|---|
comment:1 by , 22 years ago
| Owner: | set to |
|---|
comment:3 by , 22 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 , 22 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 , 22 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?
comment:6 by , 22 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 , 22 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 , 22 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 , 22 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 , 22 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 , 22 years ago
Nice to see you, Jamieson :-) Yeah the coffee problem is gone, remains to test for regressions...
comment:12 by , 22 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:14 by , 22 years ago
I guess if no regresions have been reported, the fix should be fine. Closing.
comment:15 by , 22 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Saved game right before bug