Opened 3 years ago
Last modified 22 months ago
#13366 pending defect (pending)
SCUMM: Loom (EGA) - Path finding or overlay issue at Dragon's caves
Reported by: | antoniou79 | Owned by: | athrxx |
---|---|---|---|
Priority: | normal | Component: | Engine: SCUMM |
Version: | Keywords: | pathfinding, overlay | |
Cc: | Game: | Loom |
Description (last modified by )
This in on Windows 10 x64, with a recent local build from HEAD master of 2.6.0git, testing with LOOM DOS EGA, using the orchestral audio feature.
For this I've applied the patch for the MT-32 upgrade to LOOM and set my Audio settings for the game to use "MT-32 emulator" as Music device. You may also need to do that for the attached save game to work.
How to reproduce:
Upon entering the caves, and casting the spell for Night Vision, walk to the cave entrance to the right and enter it.
What happens:
Sometimes but not always, Bobbin won't be shown to enter into the cave but instead he walks a bit to the left while clearly being outside of it. The game then teleports him to a random cave.
What should happen:
Bobbin should go into the cave and then be teleported to a random cave.
I'm including a save game at the point of entering the cave, and a screenshot showing Bobbin a bit before the game teleports him.
Attachments (5)
Change History (22)
by , 3 years ago
Attachment: | scummvm-loom-ega-00011.png added |
---|
by , 3 years ago
Attachment: | loom-ega.s57 added |
---|
comment:1 by , 3 years ago
Description: | modified (diff) |
---|
comment:2 by , 3 years ago
comment:4 by , 3 years ago
You're right the draft for night vision is: CDDC
I am not sure if it depends on where you click exactly. I had it happen by clicking in different spots. I guess the most consistent is when I click near or at the bottom left black pixel of that cave (where the cursor is in the new screenshot I'm attaching.
by , 3 years ago
Attachment: | scummvm-loom-ega-00017.png added |
---|
comment:5 by , 3 years ago
Here's also a short video showcasing Bobbin walking properly in the cave the first time, and with the bad overlay issue the second time:
https://www.youtube.com/watch?v=8xHeO3yUaDo
comment:6 by , 3 years ago
If it's of any help in comparing the behavior, I attached a set of savegames from the original interpreter to https://bugs.scummvm.org/ticket/13367
comment:8 by , 3 years ago
Also, would be good to know whether it is a regression.
(I am currently on vacation, so I won't be able to spend too much time on the ticket this week)
comment:9 by , 3 years ago
I haven't even tried reproducing this yet, and I have no idea if it's a regression or not. Unfortunately, there don't seem to be any boot params in Loom. Maybe it can be cheated with the "room" command?
comment:10 by , 3 years ago
The randomness seems to be a feature of the original game. I think this is the script (roomobj-30-512.dmp) for one of the exits:
Events: 38 - 0016 [0016] (40) cutscene([]); [0018] (70) lights(8,0,0); [001C] (16) Local[0] = getRandomNr(1); [0020] (28) if (!Local[0]) { [0025] (0E) putActorAtObject(1,511); [0029] (2E) delay(60); [002D] (70) lights(12,0,0); [0031] (1E) walkActorTo(1,496,70); [0037] (18) } else { [003A] (0E) putActorAtObject(1,513); [003E] (2E) delay(60); [0042] (70) lights(12,0,0); [0046] (1E) walkActorTo(1,549,121); [004C] (**) } [004C] (AE) WaitForActor(1); [004F] (C0) endCutscene(); [0050] (00) stopObjectCode(); END
It wouldn't surprise me, since Brian Moriarty has a bit of a history of adding randomness to uncharted terrain. Trinity, in particular, had a desert that got pretty confusing if you tried to take shortcuts instead of sticking to the roads.
comment:11 by , 3 years ago
I can reproduce the glitch with DOS EGA and FM-TOWNS. I don't know if it is a ScummVM bug or an issue also present in the original, though.
follow-up: 13 comment:12 by , 3 years ago
Owner: | set to |
---|---|
Resolution: | → pending |
Status: | new → pending |
I have made an attempt to fix this. Please test whether this works for you...
comment:13 by , 3 years ago
Replying to athrxx:
I have made an attempt to fix this. Please test whether this works for you...
Tested with Loom EGA Dos, and the overlay in the cave is fixed (for what I can tell, I tested multiple times).
However, I now see a (small) glitch that I did not notice before and I'm unsure as of yet if it is connected to the fix.
The glitch is thus: when entering a specific one of the lower caves that sends Bobbin randomnly to another cave, if that cave is the top right one (the one that previously had the overlay / path issue) then a part of Bobbin's distaff appears first, before the "light" box and Bobbin appear.
I'm attaching a save game with the cave I'm referring to and a screenshot with the glitch. One needs to keep re-loading (or retrying but only with this specific cave) until Bobbin is sent to the upper right cave to see the issue. The issue does not seem to happen if Bobbin enters or is sent to another cave.
by , 3 years ago
Attachment: | scummvm-loom-ega-00029.png added |
---|
by , 3 years ago
Attachment: | loom-ega.s90 added |
---|
comment:14 by , 3 years ago
The fix was for a path finding issue. The engine assumed that the object (the cave entrance) was within the same walk box as the actor, so he would walk straight towards it (instead of through the cave entrance. The part of the code that caused this is present in the original interpreters of the later versions (> SCUMM 5), but not in Scumm 3 or 4.
So I am quite sure that the graphics glitch you now seem to have discovered is something different.
I have now been able to reproduce it. Honestly, it doesn't even look like a drawing bug to me. It seems that Bobbin is teleported "behind" the cave entrance, but still right enough to have a couple of pixels come through the entrance. We need to check if the original doesnt look exactly like that, too...
Edit: Weird though, that it doesn't seem to happen always (even with that top right cave).
follow-up: 16 comment:15 by , 3 years ago
This is really a bit weird (not the original ticket, but the new findings).
It seems that there are two caves that lead to the top right one.
With the one down/left of the entrance, when Bobbin walks out of the top right cave you get to see the top of the distaff first (that minor graphics glitch) and it is possible to walk right back into the top right cave. When entering the other cave (right under the entrance, two rows down), Bobbin will walk out of the top right cave without the "distaff graphics glitch", but the cave is blocked somehow and can't be re-entered by just clicking on it (the script just never calls o5_walkActorToObject()); you have to walk a bit to the left or right before being able to enter again. I have checked the original FM-TOWNS interpreter with the UNZ emulator and it seems that you never get to see the glitch there (which could just be due to the smooth scrolling), but you also can't re-enter the cave when you come from the cave down/left. So, the not-being-able-to-reenter thing seems to be poor scripting.
I haven't tried DOS, I don't have a savegame for that scene. So I don't know about the distaff glitch yet.
comment:16 by , 3 years ago
Replying to athrxx:
I haven't tried DOS, I don't have a savegame for that scene. So I don't know about the distaff glitch yet.
As mentioned above, there's a set of original savegames for English EGA Loom in https://bugs.scummvm.org/ticket/13367 so maybe that helps?
comment:17 by , 22 months ago
Recently I made a change to the handling of "invalid" walkboxes for v3-4 because of a glitch in MI1 VGA Floppy. (https://github.com/scummvm/scummvm/commit/2e58159d50f2a9d1d3ad2e17a656233dfc3e0aac)
Does the change by any chance help the newly found issue mentioned in this ticket?
I haven't been able to reproduce this with FM-Towns so far. So I am trying your savegame. What are the notes for the darkness/light draft, please? These are randomized...