#987 closed defect (fixed)
LOOM: Some bits of dialogue are repeated
Reported by: | SF/dfabulich | Owned by: | fingolfin |
---|---|---|---|
Priority: | normal | Component: | Engine: SCUMM |
Version: | Keywords: | script | |
Cc: | Game: | Loom |
Description
In the attached save, double-click on Rusty. Bobbin will say "Strange place to take a nap" twice. This happens at random throughout the game, but this was the easiest place to reproduce it.
Win2K, ScummVM 0.5.0pre-cvs Built on Jul 10 2003 20:29:19.
Ticket imported from: #770042. Ticket imported from: bugs/987.
Attachments (1)
Change History (7)
by , 21 years ago
comment:1 by , 21 years ago
I don't know about this particular case, but in at least one case I looked at a while ago the script actually printed the message twice. Probably because if it was only printed once it'd time out too soon. When I tried the same scene with the original interpreter, the text wasn't removed in between the two printings. In ScummVM it was.
It's still a bug, of course. I just wanted to point out a possible explanation. :-)
comment:2 by , 21 years ago
Summary: | Loom EGA: Some bits of dialogue are repeated → LOOM: Some bits of dialogue are repeated |
---|
comment:3 by , 21 years ago
The "Strange place to take a nap" is also printed twice. The script basically has a small loop like this: for(i = 0; i<2; i++) { print(...) waitForMessage(); }
Now, the script prints the text once, then reaches the waitForMessage(), which puts the script to sleep until the message is removed from the screen. Then once the message times out, the following happens: it times out, which leads to stopTalk to be called, which redraws the screen area the text was in. *then* at the end of the scumm loop iteration, the screen is redrawn. Then in the next iteration of the scumm loop, scripts are processed. Our sleeping script resumes, and prints the message again. As a result, there is (at least) one frame without the text visible.
The only way to "fix" this would be, AFAICT, to change the order in which message/script/redraw processing are done. However, the current order definitely is right for the majority of games, and I'd be surprised to learn that Loom is different here... maybe there is some other subtle difference we are not properly covering yet.
comment:4 by , 21 years ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:5 by , 21 years ago
Actually, I rechecked some disassembly, and the order *is* different for V1-V3 games (well at least for Loom and Zak - somebody should verify this in Indy).
comment:6 by , 21 years ago
Cool. I can verify this in Indy when I get home. How would this bug manifest itself in general? What kind of regressions should I be looking for?
Saved game right in front of Rusty