Opened 19 years ago
Closed 19 years ago
#2068 closed defect (fixed)
SAM: Animation glitch at World of Fish
| Reported by: | eriktorbjorn | Owned by: | cyxx |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Sam and Max |
Description
Sam & Max, English CD version Recent ScummVM CVS snapshot
With the attached savegame, when Max grabs the fishing line there's a graphical glitch: the line is drawn twice in different positions. I cannot reproduce this if I use a boot param (301) to skip to the scene, so presumably the savegame has accumulated some cruft since I started re-playing Sam & Max, a few weeks ago.
The only difference I could find in the saved part of actor 4 (the fisherman) was the _walkdata part, and resetting that made no difference as far as I could tell. I'm stumped.
Ticket imported from: #1223621. Ticket imported from: bugs/2068.
Attachments (3)
Change History (14)
by , 19 years ago
| Attachment: | samnmax.s10 added |
|---|
comment:1 by , 19 years ago
Is this a regression after our recent actor draw order changes, or an older bug?
comment:2 by , 19 years ago
I don't know. As I said, I couldn't reproduce it if I used a boot param to get there quickly, so my guess was that there was some cruft in the actor data structures.
Sort of like the flickering Chron-O-John bug we used to have in DOTT (Bug #558310) which turned out to be an animation speed variable that wasn't cleared, so a value that was intended for a different actor was used for the Chron-O-John. And for Dr. Fred in the epilogue.
Though when I tried comparing actor data between the savegame and the boot param, I didn't find any differences that looked significant to me. I'm not quite sure where to look...
comment:3 by , 19 years ago
I wanted to have a look at it but I am unable to reproduce the problem. In fact, I simply don't see the "second" fishing line you describe, Erik. Maybe I missed something obvious, but is it possible to attach a screenshot ?
comment:4 by , 19 years ago
I never was able to reproduce this either, but I thought I was simply doing something wrong / missing something obvious :-/
comment:5 by , 19 years ago
I've attached a picture that shows approximately what I see when using this particular savegame.
comment:6 by , 19 years ago
Ok. So I can confirm I am unable to reproduce the issue under win2k using mingw/gcc3.4.2.
comment:7 by , 19 years ago
I decided to try with the Windows snapshot from the ScummVM page to rule out any problems with my build environment. Then I wiped my scummvm.ini to rule out any problems with my settings.
The good or bad news - depending on your point of view - is that I can still reproduce the bug. Apparently it's rather timing-sensitive, though: It only happens if subtitles are turned on. With voice only, it looks fine. With subtitles only, it looks almost fine. With both subtitles and voice, it looks as in the attached screenshots.
Skipping any of the speech in the scene probably throws off the timing as well. Keep your hands away from the mouse and keyboard, and enjoy the show! :-)
comment:8 by , 19 years ago
The problem is indeed timing-related. script-35-202 drives the sequence :
[02CC] (BA) talkActor(:sound:"Holy trout!":startanim=7::wait:"I always thought you were made of plaster.":startanim=7:,4) [0320] (7C) stopScript(212) [0324] (43) localvar0 = 1 [032A] (5D) while (localvar0 <= 54) { [0334] (6C) breakHere() [0335] (4F) localvar0++ [0338] (**) } [033B] (82) animateActor(4,14) // draws the fisherman without the fishing line [0342] (CA) breakXTimes(10) [0346] (82) animateActor(4,15) [034D] (CA) breakXTimes(9)
If there are no subtitles, the speech sfx finishes before the first animateActor() call and everything is fine, stopTalk() is called, which 'resets' the animation of the actor. If subtitles are present, the stopTalk() call is delayed, which leads to the glitch.
I played the game with the original interpreter with subtitles on and talk speed set to the slowest, and without much surprise, the same glitch appears. So, it's definitely not a problem in ScummVM.
I am not sure to understand why they didn't use the waitForActor() opcode here...
by , 19 years ago
| Attachment: | snm-fisherman-original.png added |
|---|
Screenshot of the scene with the original interpreter
comment:9 by , 19 years ago
The problem is indeed timing-related. script-35-202 drives the sequence :
[02CC] (BA) talkActor(:sound:"Holy trout!":startanim=7::wait:"I always thought you were made of plaster.":startanim=7:,4) [0320] (7C) stopScript(212) [0324] (43) localvar0 = 1 [032A] (5D) while (localvar0 <= 54) { [0334] (6C) breakHere() [0335] (4F) localvar0++ [0338] (**) } [033B] (82) animateActor(4,14) // draws the fisherman without the fishing line [0342] (CA) breakXTimes(10) [0346] (82) animateActor(4,15) [034D] (CA) breakXTimes(9)
If there are no subtitles, the speech sfx finishes before the first animateActor() call and everything is fine, stopTalk() is called, which 'resets' the animation of the actor. If subtitles are present, the stopTalk() call is delayed, which leads to the glitch.
I played the game with the original interpreter with subtitles on and talk speed set to the slowest, and without much surprise, the same glitch appears. So, it's definitely not a problem in ScummVM.
I am not sure to understand why they didn't use the waitForActor() opcode here...
comment:10 by , 19 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Savegame at World of Fish