Opened 10 years ago
Closed 10 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)
Change History (14)
by , 10 years ago
| Attachment: | indy3-ega.s01 added |
|---|
by , 10 years ago
| Attachment: | indy3mapglitch.png added |
|---|
comment:1 by , 10 years ago
by , 10 years ago
| Attachment: | SAVEGAME._D_ added |
|---|
comment:4 by , 10 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 , 10 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 , 10 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:8 by , 10 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 , 10 years ago
digitall: You're welcome. Let me know if you guys need any more help with testing or anything.
comment:10 by , 10 years ago
This has now been fixed by rrebello in commit 30b6a479e5. Many thanks for your work! Closing as fixed.
comment:11 by , 10 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
DOSBox screenshot showing how it's supposed to display, and ScummVM screenshot showing the glitch