#461 closed defect (fixed)
LOOMCD: Glitch when healing Rusty
| Reported by: | SF/dfabulich | Owned by: | SF/ender |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Loom |
Description
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)
Change History (9)
by , 22 years ago
| Attachment: | rustyglitch.zip added |
|---|
comment:1 by , 22 years ago
Appears in ScummVM 0.2.2 CVS Built on Sep 15 2002 22:58:14
(downloaded Win32 snapshot).
comment:2 by , 22 years ago
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 by , 22 years ago
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 Z-plane.
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 by , 22 years ago
I also cannot reproduce problem 1 on the current build. Good luck on the second problem.
comment:5 by , 22 years ago
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 by , 22 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:7 by , 22 years ago
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 by , 22 years ago
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.
Zip containing two PNGs and a saved game