Opened 14 years ago
Last modified 4 years ago
#5667 new defect
HUGO: Whodunit? - Priority glitches in Main Hall
| Reported by: | raziel- | Owned by: | Strangerke |
|---|---|---|---|
| Priority: | normal | Component: | Engine: Hugo |
| Version: | 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)
Change History (20)
by , 14 years ago
| Attachment: | HUGO - Whodunit-Penelope glitch-1.png added |
|---|
by , 14 years ago
| Attachment: | HUGO - Whodunit-Penelope glitch-2.png added |
|---|
Penelope leaving the scene on the left
comment:1 by , 14 years ago
| Owner: | set to |
|---|
comment:2 by , 12 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..
comment:3 by , 12 years ago
| Summary: | HUGO: Priority glitches in Whodunit? (Main Hall)) → HUGO: Priority glitches in Whodunit? (Main Hall) |
|---|
comment:4 by , 12 years ago
I uploaded two new save files (which shouldn't crash) which show the exact positions when this glitch happens
comment:6 by , 12 years ago
| Priority: | normal → high |
|---|
comment:7 by , 12 years ago
This bug is nice to get fixed before the release. Raising priority for keeping the track.
comment:9 by , 12 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 , 12 years ago
| Attachment: | hugo-mask.png added |
|---|
Partial screenshot of the right side, with the overlays
comment:10 by , 12 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 , 12 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.)
comment:12 by , 4 years ago
| Summary: | HUGO: Priority glitches in Whodunit? (Main Hall) → HUGO: Whodunit? - Priority glitches in Main Hall |
|---|
comment:13 by , 4 years ago
| Priority: | high → normal |
|---|
Right door