Opened 9 years ago

Last modified 7 years ago

#5667 new defect

HUGO: Priority glitches in Whodunit? (Main Hall)

Reported by: raziel- Owned by: Strangerke
Priority: high Component: Engine: Hugo
Keywords: Cc:
Game: Hugo

Description

ScummVM 1.3.0git (Apr 23 2011 09:51:43)
Features compiled in: Vorbis FLAC MP3 RGB zLib Theora

After reaching the main hall and nearly the end of the game Penelope has broken in the safe and on leaving the room she passes two spots where the background (door) draws over her sprite.

Savegame and both screenshots attached

Hugo 2: Whodunit? (DOS/English)

AmigaOS4 - PPC - SDL - BE
gcc (GCC) 4.2.4 (adtools build 20090118)

Ticket imported from: #3292383. Ticket imported from: bugs/5667.

Attachments (7)

HUGO - Whodunit-Penelope glitch-1.png (14.8 KB ) - added by raziel- 9 years ago.
Right door
HUGO - Whodunit-Penelope glitch-2.png (14.8 KB ) - added by raziel- 9 years ago.
Penelope leaving the scene on the left
hugo2-17.SAV (6.2 KB ) - added by raziel- 7 years ago.
First glitch showing it right after loading
hugo2-18.SAV (6.2 KB ) - added by raziel- 7 years ago.
Second glitch showing it right after loading
HHH7.SAV (5.9 KB ) - added by raziel- 7 years ago.
DosBox save in the Main Hall
hugo-glitch.png (2.1 KB ) - added by eriktorbjorn 7 years ago.
Partial screenshot of the right-side glitch
hugo-mask.png (1.8 KB ) - added by eriktorbjorn 7 years ago.
Partial screenshot of the right side, with the overlays

Download all attachments as: .zip

Change History (18)

by raziel-, 9 years ago

Right door

by raziel-, 9 years ago

Penelope leaving the scene on the left

comment:1 by digitall, 9 years ago

Owner: set to Strangerke

comment:2 by digitall, 8 years ago

Tried loading this savegame to replicate with the latest Git master and this provokes a segfault crash.
Running with valgrind shows a significant number of memory access errors, preventing successful loading.
By checking out bec42f78b7e6ff36e1896d1dde7060f935b723e7 which I think is the point where the savegame was originally created, this loads, but crashes fairly quickly with segfaults.
This point was just prior to a number of commits correcting valgrind detected issues and various BE related issues in Sound loading and savegames. It is likely that the savestate attached is corrupted.

It will be necessary to play most of Hugo 2 through to this point under DOSBox to produce a reference savegame there and to see if this occurs in the original.
Similarly, it should also be replayed from a clean state with the latest Git master to get a savegame which is not corrupted and to see if the issue still occurs..

by raziel-, 7 years ago

Attachment: hugo2-17.SAV added

First glitch showing it right after loading

by raziel-, 7 years ago

Attachment: hugo2-18.SAV added

Second glitch showing it right after loading

comment:3 by raziel-, 7 years ago

Summary: HUGO: Priority glitches in Whodunit? (Main Hall))HUGO: Priority glitches in Whodunit? (Main Hall)

comment:4 by raziel-, 7 years ago

I uploaded two new save files (which shouldn't crash) which show the exact positions when this glitch happens

comment:5 by digitall, 7 years ago

Thank you for these... Will take a look later.

comment:6 by sev-, 7 years ago

Priority: normalhigh

comment:7 by sev-, 7 years ago

This bug is nice to get fixed before the release. Raising priority for keeping the track.

by raziel-, 7 years ago

Attachment: HHH7.SAV added

DosBox save in the Main Hall

comment:8 by raziel-, 7 years ago

This glitches does not happen in DosBox (DosBox save attached)

comment:9 by eriktorbjorn, 7 years ago

I don't really understand how Hugo handles drawing, but it looks like there is an "overlay" that indicates which parts of the screen can mask an object being drawn to give the appearance that it's behind the object. On the right side of the room, there is a mask to hide you as you walk through the upper right door, and I think that's what's incorrectly hiding you as you walk through the lower right door.

(I'm not sure if I see the glitch on the left side, but it looks like it's sometimes *not* hiding you as you walk through the door.)

So I'm guessing the overlay itself is correct, but we somehow get it wrong when deciding whether or not to use it. That could indicate a problem in findOvl(), but I don't know.

by eriktorbjorn, 7 years ago

Attachment: hugo-glitch.png added

Partial screenshot of the right-side glitch

by eriktorbjorn, 7 years ago

Attachment: hugo-mask.png added

Partial screenshot of the right side, with the overlays

comment:10 by eriktorbjorn, 7 years ago

I should have looked at the screenshots before I said I wasn't sure if I saw the left-side glitch. :-)

Anyway, I've uploaded two partial screenshots. One of the glitch. This is pretty much the same as the screenshot that was already attached, but it's for comparison with the second partial screenshot where I've tried to get it to draw the overlays.

If I got it right, the blue area is the parts that can obscure the sprite, while the cyan line at the bottom of the blue area is the indicator for whether or not a sprite should be obscured.

For any visible pixel in the sprite, it look at that pixel and all the pixels (visible or not) below it, to the bottom of the sprite's bounding box. As soon as it finds any pixel overlapping this cyan line, the rest of the sprite is automatically not obscured. I think.

In this screenshot, Penelope's face is probably hidden because while part of her sprite is below the cyan line, those parts have no visible pixels above the line. (The line ends before the right edge of the blue area.)

(Actually, it's not quite that simple because Screen_v1d::findOvl(), which is the version of the function used for the version of the game I tried, looks at one byte at a time, not one bit. I need sleep...)

comment:11 by eriktorbjorn, 7 years ago

I could be wrong, but I get the impression that our displayFrame() is based on the Windows version of the Hugo games. The DOS version appears to do the drawing in two steps: One to determine if the sprite is in the foreground or in the background, and one to actually draw it.

I thought I would be able to do a simple fix, but it didn't work. It probably needs to match the original behavior much more closely than I'm able to do. (We do have the original source code, as noted in the ScummVM credits, but that particular function is mostly assembly, which I don't speak.)

Note: See TracTickets for help on using tickets.