Opened 10 years ago

Closed 9 years ago

#6679 closed defect (fixed)

INDY3 DOS-EGA: book of maps graphic glitch

Reported by: SF/diggly Owned by: bluegr
Priority: normal Component: Engine: SCUMM
Version: Keywords:
Cc: Game: Indiana Jones 3

Description

mingw-w64-stable-c36867d1 1.7.0pre-24-gc36867d (64-bit) on Windows 7 64-bit

When looking at the book of maps, there is a big pink box that obfuscates half of the page, and cuts the text off.

I did not encounter this glitch when using the original .exe in DOSBox

To recreate from save, click open, then click book of maps

Ticket imported from: bugs/6679.

Attachments (3)

indy3-ega.s01 (11.7 KB ) - added by SF/diggly 10 years ago.
indy3mapglitch.png (65.2 KB ) - added by SF/diggly 10 years ago.
SAVEGAME._D_ (13.3 KB ) - added by SF/diggly 10 years ago.

Download all attachments as: .zip

Change History (14)

by SF/diggly, 10 years ago

Attachment: indy3-ega.s01 added

by SF/diggly, 10 years ago

Attachment: indy3mapglitch.png added

comment:1 by SF/diggly, 10 years ago

DOSBox screenshot showing how it's supposed to display, and ScummVM screenshot showing the glitch

by SF/diggly, 10 years ago

Attachment: SAVEGAME._D_ added

comment:2 by SF/diggly, 10 years ago

DOSBox save

comment:3 by SF/diggly, 10 years ago

00.lfl md5 is 5fbe557049892eb4b709d90916ec97ca game version EN v1.0

comment:4 by bluegr, 9 years ago

This is really weird. The presence of this purple box depends on Indy's position!

Try opening the book when he's at the right of the screen ---> box appears But when he's on the left ---> no box (!!!)

To replicate without a saved game: teleport to room 171 and pick up the book on the rightmost side (2nd row from the bottom, to the right). Then, "Open book".

This does not occur in the VGA version

comment:5 by bluegr, 9 years ago

Also, the book is in room 64 (it's funny to simply switch in that room, cause you can still see indy walking around)

comment:6 by SF/rrebello, 9 years ago

This is interesting. As far as I can tell, the problem only occurs in this particular variant of Indy3 DOS EGA with 00.lfl md5 equal to 5fbe557049892eb4b709d90916ec97ca (that's v1.0, according to devtools/scumm-md5.txt). I've tested the VGA and the Amiga versions, as well as a DOS EGA variant with a different 00.lfl md5 (6b3ec67da214f558dc5ceaa2acd47453, v1.3), and the glitch doesn't show up in ANY of those.

What happens under the hood is that the width property of room 64 (open book of maps image) has a wrong value of 1793 in the data files of the mentioned variant, as opposed to the correct 320 that I've seen in all other versions, which makes the room "scrollable" since 1793 is larger than the screen width (320). This, combined with the fact that ScummEngine::startScene() sets camera._mode to kNormalCameraMode and does NOT reset the state variable camera._movingToActor to false, causes the camera to scroll towards Indy's last known position from the previous room in some cases, revealing the weird pink background. More specifically, the scrolling occurs when the switch to room 64 happens at moments in which camera._movingToActor is true and camera._dest.x is set to any value greater than 160. This is the case, for example, when Indy is in the far right corner of a room, since in that situation camera._movingToActor is constantly being set to true in every call to ScummEngine::moveCamera(), but the camera doesn't move because its position gets clamped to VAR(VAR_CAMERA_MAX_X). That explains why the glitch occurrence is dependent upon Indy's position.

One possible fix for the problem is to simply add the assignment of camera._movingToActor to false in ScummEngine::startScene() when camera._mode is set to kNormalCameraMode, which prevents the camera from following the actor's last X position. That seems like the most sensible solution to me, as that assignment makes perfect sense and is clearly missing in this case. Moreover, this is what is done when camera mode is changed from inside ScummEngine::setCameraAtEx() and ScummEngine::panCameraTo(), for example.

I've done some testing and the change looks OK, so I'll submit a pull request for this fix.

comment:7 by SF/rrebello, 9 years ago

The fix has been submitted as Pull Request #527.

comment:8 by digitall, 9 years ago

rrebello: Thanks for tracking this bug down and submitting a patch as: https://github.com/scummvm/scummvm/pull/527

It may take some time for the SCUMM engine team to review this, so please standby. Thanks again.

comment:9 by SF/rrebello, 9 years ago

digitall: You're welcome. Let me know if you guys need any more help with testing or anything.

comment:10 by bluegr, 9 years ago

This has now been fixed by rrebello in commit 30b6a479e5. Many thanks for your work! Closing as fixed.

comment:11 by bluegr, 9 years ago

Owner: set to bluegr
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.