#791 closed defect (fixed)
INDY3: Marcus on foreground
| Reported by: | SF/hibernatus | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Indiana Jones 3 |
Description
Load the attached file and you will see Marcus standing on the table (making a speech? :) What's interesting is that he is the only one with this bug (see Indy).
Ticket imported from: #740244. Ticket imported from: bugs/791.
Attachments (2)
Change History (16)
by , 21 years ago
comment:1 by , 21 years ago
woops i forgot the usual things: ScummVM 0.4.1cvs Built on May 20 2003 13:35:27
Happens in the cut scene when you first go to Venice.
comment:2 by , 21 years ago
| Owner: | set to |
|---|
comment:3 by , 21 years ago
That save game is sadly useless to debug the problem. We need one *before* that happens - with this save game, it'll always be wrong, even if I fix the problem :-)
comment:4 by , 21 years ago
I should have thought about that indeed, but anyway you can get the bug after 24 seconds of playing :) Here is a save game in the previous room this time.
comment:5 by , 21 years ago
On the other hand, since you don't need the grail diary or anything from Henry's house to go to Venice, it shouldn't take you much more than 30 seconds to get to Venice, if you escape through the intro and the Donovan cutscene. :-)
comment:6 by , 21 years ago
Didn't realize that it's so close to the start of the game :-)
Problem is, marcus is in walkbox 255 (i.e. the invalid walk box), so he's drawn in zplane 0. I have no clue, right now, *why* he is in that walkbox. Hm.
comment:7 by , 21 years ago
Marcus (actor 4) is in box 255 because he's set to ignoreBoxes=true. He is not set to do that in that room, though (unlike actor 10, Dr. Schneider, who is set to ignoreBoxes). So I guess he was set to ignoreBoxes at some earlier point. Which makes me wonder if maybe we should've reset the ignore flag at some point?
comment:8 by , 21 years ago
update: With 0.4.1 the bug is gone. But with 0.4.2cvs (built today) the bug is back. Something to notice: when you finish the catacombs part, marcus comes back for another cutscene. This time he is behind the table, but not the puddle which grows under his feet.
comment:9 by , 21 years ago
The bug was probably introduced in the trunk after 0.4.0 was branched. 0.4.1 is based on that branch.
comment:10 by , 21 years ago
As erik says.To further explain this, I perfectly understand what is causing the symptoms, and I could easily introduce a hackish FIX (and I might just do that soon if I can't find the proper solution).
But, I'd prefer to understand the actual cause and resolve that, instead of just curing the symptoms.
I.e.: Should Marcus somehow have been reset to not ignore boxes at some point? if so where and why don't we register it. Or maybe, Marcus is supposed to be in "ignore boxes" mode, but should still check in which box he is and use the mask for that box... but that doesn't seem to be at all what the original code does, so I'd be reluctant to do that. Or maybe he should be set to "forceClip" mode and for some reasons we don't do that... etc. etc., there are multiple possible reasons.
Hey, erik, if you feel bored... =)
comment:11 by , 21 years ago
I've tested the original engine by changing the scripts twice.
1. Replaced: [0097] (D8) printEgo([Text("Maybe he'll recognize us.")]) by: [0097] (5D) setClass(4,[148]) // neverClip That makes marcus instantly move onto foreground.
2. Replaced: [0097] (D8) printEgo([Text("Maybe he'll recognize us.")]) by: [0097] (5D) setClass(4,[150]) // ignoreBoxes That doesn't do anything.
Maybe somebody could check the exe, but i think the class kObjectClassIgnoreBoxes shouldn't put actors on foreground. That would fix the FIXME in object.cpp line 104, and the bug #755863 (zak256).
comment:12 by , 21 years ago
That's a misunderstanding. kObjectClassIgnoreBoxes does *not* put actors in the foreground. Rather it does cause actors to ignore boxes.
What you see is an indirect consequence: affected actors are in no box (or if you prefer, they are in box 255, the invalid box). As a consequence of that, the actor will be always in zplane 0 in ScummVM. This is what is causing the effect reported in this bug.
From all I can see in the MIVGA engine (don't have Indy3 disassmbly) this is the correct behaviour. Actually, it looks a bit as if their code was buggy: if an actor is in no box, the actor is set to the special box 255 (=invalid box). The function which determines the zplane value for a given box doesn't perform bound checking. Furthermore, the code calling it doesn't seem to perform bound checking.
So why does it work anyway in the original? One theory: Unless code was different in the Indy3 / Zak256 engine, it would seem that an out-of-bound access occured. By chance, the value returned was non-0 in the original engine. leading to an apparently "correct" display.
comment:13 by , 21 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:14 by , 6 years ago
| Component: | → Engine: SCUMM |
|---|---|
| Game: | → Indiana Jones 3 |
Marcus on foreground