Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#461 closed defect (fixed)

LOOMCD: Glitch when healing Rusty

Reported by: SF/dfabulich Owned by: SF/ender
Priority: normal Component: Engine: SCUMM
Keywords: Cc:
Game: Loom


1) As you pop through the hole and talk to Rusty's
ghost, various visible glitches occur, including the
Ego's feet popping out from behind a blocking
gravestone [afterchat.png].

2) After you heal Rusty (c a a c in the attached saved
game), Rusty will be incorrectly halfway obscured by
the Pattern Rip [afterheal.png].

Ticket imported from: #609716. Ticket imported from: bugs/461.

Attachments (1) (198.3 KB) - added by SF/dfabulich 17 years ago.
Zip containing two PNGs and a saved game

Download all attachments as: .zip

Change History (9)

Changed 17 years ago by SF/dfabulich

Attachment: added

Zip containing two PNGs and a saved game

comment:1 Changed 17 years ago by SF/dfabulich

Appears in ScummVM 0.2.2 CVS
Built on Sep 15 2002 22:58:14

(downloaded Win32 snapshot).

comment:2 Changed 17 years ago by eriktorbjorn

I couldn't repeat the first problem, but the second goes
away if I keep the hole object from being drawn. It might be
a problem with how the object mask is applied and/or
decoded, but I have yet to figure out what the problem is.
I'll keep looking...

comment:3 Changed 17 years ago by eriktorbjorn

After comparing to what the scene looks like in the original
interpreter, I no longer think it's a masking problem even
if the mask *is* weird. When Rusty walks to the left, he
should be walking in *front* of the tombstone, not behind
it, so it's more likely that he's being drawn on the wrong

This is probably a consequence of him being moved around
without regard to walk boxes, so ScummVM considers him to be
in box 0. I have some ideas on how to fix - or at least work
around - this. I'll try them later today.

comment:4 Changed 17 years ago by SF/dfabulich

I also cannot reproduce problem 1 on the current build.
Good luck on the second problem.

comment:5 Changed 17 years ago by SF/ender

Fixed in the latest CVS tree by eriktorbjorn's walkbox 0 checking.

(It's annoying, we used to have code in there to handle this case, except
that then earlier games started considering walkbox 0 as a valid walkbox,
whereas in older games it's considered an 'unknown')

comment:6 Changed 17 years ago by SF/ender

Owner: set to SF/ender
Resolution: fixed
Status: newclosed

comment:7 Changed 17 years ago by fingolfin

Just to explain some further what is going wrong here: In
newer games, walkbox 0 is a special "huge" box; when you are
in no other box, you'll be in box 0. That simplifies some
code, and it allows us to assume box == 0 means "out of any
other box". This kind of trick is the same as using a
sentinel for a linked list etc. - it allows you to get rid
of all sorts of special cases in your code etc.

In the old (small header games) code, though, this was
different. The boxes started at 0, and box 0 was a normal
box like any other. That meant they had to add all sorts of
boundary case checks etc. Apparently, "out of any other box"
was marked by stowing -1 == 255 into the box fields.

I tried to implement it "right", but that requires to change
a lot of code, and remove several old FIXME's, plus it will
mean that some save games won't work correctly anymore, so
for now I've put that patch on ice. I might look again into
this after 0.3.0.

comment:8 Changed 17 years ago by fingolfin

Reviewing this, what I said was not completly right: the 0
walkbox in newer games has all coords equal to (-32000,-
32000), so it doesn't cover everything. Still, the overall
theme is right. Note that we still have several places that
look like: if (!walkbox) - this of course causes problems
in small header games, and is the reason we have to add
hacks/FIXMEs to get them to behave right.

Note: See TracTickets for help on using tickets.