#774 closed defect (fixed)
DIG: Cursor image appears in upper left corner
Reported by: | eriktorbjorn | Owned by: | fingolfin |
---|---|---|---|
Priority: | normal | Component: | Engine: SCUMM |
Version: | Keywords: | ||
Cc: | Game: | The Dig |
Description
The first time you adjust the blue rods to activate the dead crystal in The Dig, a picture of the cursor (up/down arrow) appears in the upper left corner.
(This could possibly be somewhat related to bug #737387, "SAM: Part of text (subtitles) disappears when moving mouse", but the fix for that one has no effect on this one.)
The bug appears in recent CVS snapshots with the English version of The Dig, but I believe it has been there for a long time.
Ticket imported from: #738352. Ticket imported from: bugs/774.
Attachments (1)
Change History (14)
by , 21 years ago
Attachment: | dig.s45.gz added |
---|
comment:1 by , 21 years ago
The first step towards solving this would be to find out which code is reponsible for drawing the cursor graphics in the top left of the screen. It's not setCursorImg, that much is know...
comment:2 by , 21 years ago
I don't understand what's going on, but this is what appears to be happening:
Object 690 is added to room 93 by addObjectToInventory().
Object 690 is "removed" with removeObjectFromRoom(), called from o6_pickupObject().
Object 690 is drawn as part of drawRoomObjects().
It's the third step that I don't understand. Surely, if an object has been picked up it's no longer one of the room objects? And removeObjectFromRoom() seems misnamed because as far as I can see it doesn't really remove the object. It just forces that part of the screen to be redrawn.
I haven't tried to make sense of the scripts yet, but it looks like it's script-18 that's doing things:
[008B] (9B) resourceOps.loadFlObject(localvar0) [0090] (5D) if (getVerbEntrypoint(localvar0,91)) { [009A] (60) startObject(2,localvar0,91,[]) [00A7] (5D) if (ifClassOfIs(var252,[30])) { [00B4] (7C) stopScript(0) [00B8] (**) } [00B8] (73) } else { [00BB] (7C) stopScript(0) [00BF] (**) } [00BF] (84) pickupObject(localvar0)
room-100-2001 invokes the script with startScript(0,18,[690])
comment:3 by , 21 years ago
Objects are never really "removed" from a room - only 'hidden'. What happens if you pick up an object, roughly, is that * copy the object code into an 'inventory' resource * set the object owner to be the player * put the object into the 'untouchable' class (so that clicking on it in the room doesn't work anymore) * put it into state 1
The object then is still being drawn, however, normally for that state the object frame is either empty or blends into the room scenery, so it essentially gets 'invisible'.
comment:4 by , 21 years ago
The key here is that the object gets turned into an flObject and hence shouldn't be drawn in the room anymore. I *think* so at least. I just commited an according fix to CVS, but it might cause regressions in other places. We'll see....
comment:5 by , 21 years ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:6 by , 21 years ago
Reverted Fingolfins bugfix for #738352 (object.cpp revision 1.162), which caused Sam and Max inventory regression #877798.
Closing 877798 and reopening 738352.
As far as this bug goes, I just reverted the whole change as it didn't "feel right" to me.
comment:7 by , 21 years ago
Status: | closed → new |
---|
comment:8 by , 21 years ago
Owner: | changed from | to
---|
comment:9 by , 21 years ago
To meit doesn't "feel right" that this bug is still assigned to me then <shrug> :-)
comment:10 by , 21 years ago
Owner: | removed |
---|
comment:12 by , 21 years ago
Owner: | set to |
---|---|
Status: | new → closed |
comment:13 by , 21 years ago
Fix verified against disasm but should only apply to scumm7+ and HE games.
Savegame at the rods and crystals