#1587 closed defect (fixed)
DIG: Large delay in 'library' room
| Reported by: | SF/eazycheeze | Owned by: | Kirben |
|---|---|---|---|
| Priority: | high | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | The Dig |
Description
ScummVM 0.7.0CVS (Apr 9 2004 18:00:49) Features compiled in: Vorbis FLAC MP3 zLib MPEG2
English Talkie version of the Dig. Win32 build.
Attached save game starts out in the Museum, just after getting the red engraved rod. Then I walk into the very green library-type room where Maggie is, and we talk for a bit, except every line is accompanied by a delay of at least 30 seconds. Then after the conversation is over, the game locks up pretty much totally; I can sometimes hit F5 to get into the menu, but that's it.
Ticket imported from: #932574. Ticket imported from: bugs/1587.
Attachments (1)
Change History (15)
by , 21 years ago
| Attachment: | dighangsave.rar added |
|---|
comment:1 by , 21 years ago
| Summary: | Large delay in 'library' room → DIG: Large delay in 'library' room |
|---|
comment:2 by , 21 years ago
Sounds like a regression in the talk system. Either caused by my recent changes to it, or by aquadran's iMuse changes. Though right now I don't see how any of my changes could cause this (but of course, that just means I don't see it, nothing else ;-).
Aquadran, any ideas?
comment:3 by , 21 years ago
Great timing. I've just noticed the same bug yesterday night with my French copy of The Dig for MacOS. Checked again with the latest Win32 build (April 11, 2004, 6:55 am) and still the same. Somehow I could zap the whole conversation (ESC key) and exit the Library (double click on Exit). From then I could go on and complete the game without any further issue -- provided that I don't enter the Library again (with or without Maggie in it). It doesn't seem to be exclusively related to the talk system since the lock-ups can also happen while doing nothing.
comment:4 by , 21 years ago
Same problem here, Italian version
I ran scummvm -d 6, in the debug output I see ImuseSetState (92) Set music state: stateMuseumLibrary, MUB575~5.IMU Locking mutex IMuseDigital::fadeOutMusic() IMuseDigital::fadeOutMusic Unlocking mutex IMuseDigital::fadeOutMusic() startMusicBundle(MUB575~5.IMU) Locking mutex IMuseDigital::startSound() IMuseDigital::startSound(1450) Unlocking mutex IMuseDigital::startSound() Locking mutex IMuseDigital::callback() switchToNextRegion-sound(1450) select 0 region, curHookId: 0 Unlocking mutex IMuseDigital::callback() Locking mutex IMuseDigital::callback()
and then a ton (thousands of rows) of:
Unlocking mutex IMuseDigital::callback() Locking mutex IMuseDigital::callback() Unlocking mutex IMuseDigital::callback() Locking mutex IMuseDigital::callback() Unlocking mutex IMuseDigital::callback() Locking mutex IMuseDigital::callback() Unlocking mutex IMuseDigital::callback() Locking mutex IMuseDigital::callback()
comment:6 by , 21 years ago
| Owner: | set to |
|---|
comment:7 by , 21 years ago
Please... higer the priority... i can't finish game without go in the library, in the final part you *must* go in the library, can't avoid it forever...
comment:9 by , 21 years ago
| Owner: | removed |
|---|
comment:10 by , 21 years ago
it doesn't sound like imuse digital bug. with completly disabled imuse problem still occurs.
comment:11 by , 21 years ago
| Priority: | normal → high |
|---|
comment:12 by , 21 years ago
Any suggestion for a workaround? Stable version has buggy actions description in italian version.
comment:13 by , 20 years ago
The problem was caused by scumm/akos revision 1.115, the clipping checking was changed and it ended up too strict, causing a tight loop. Fixed in Scumm CVS by reverting that change.
comment:14 by , 20 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
The save game in question