Opened 5 years ago

Closed 2 years ago

Last modified 12 months ago

#10854 closed defect (fixed)

SCUMM: MI1 (Floppy) - Color cycling in lava cave backwards

Reported by: GermanTribun Owned by: dwatteau
Priority: normal Component: Engine: SCUMM
Version: Keywords:
Cc: Game: Monkey Island 1


Game: Monkey Island 1 German Floppy Version
ScummVM: 2.0.0

There's a really bizarre behavior in the lava cave under Monkey Island. The color cycling of the lava runs backwards, thus the lava seems to flow up instead of down, which also reveses the effect on the lava lake, but it's better visible in the lavafalls, especially the one in the first room.

This strange behavior only affects the floppy version, as the CD version has the correct effect. I could only test it with ScummVM 2.0.0 since the Snapshot simply crashed after installation (bad luck, I guess). I have no idea if it affecxts other color cycling routines as well.

Attachments (3)

MONKEY.s10 (24.6 KB ) - added by GermanTribun 5 years ago.
SAVEGAME._H_ (24.6 KB ) - added by GermanTribun 5 years ago.
SAVEGAME._B_ (18.7 KB ) - added by dwatteau 2 years ago.
DOS savegame with OK lava (English VGA floppy version)

Download all attachments as: .zip

Change History (18)

comment:1 by GermanTribun, 5 years ago

Summary: Color cycling in lava cave backwardsMI1 Floppy: Color cycling in lava cave backwards

comment:2 by Mataniko, 5 years ago

Thanks for the report! Can you please attach a save file?

by GermanTribun, 5 years ago

Attachment: MONKEY.s10 added

comment:3 by GermanTribun, 5 years ago

Added the save file, Guybrush stands directly in front of the lava fall at the start. However, it affects all lava falls in the caverns (and the lava pools).

comment:4 by bonki, 5 years ago

Do you happen to have an original engine savegame?

by GermanTribun, 5 years ago

Attachment: SAVEGAME._H_ added

comment:5 by GermanTribun, 5 years ago

Yep, here one from the pure DOS-game, just saved in front of the lava fall in the first cavern. It's Savegame._H_

Hopefully that helps, because that a strange bug in ScummVM, as other color cycling works normally.

comment:6 by raziel-, 4 years ago

Summary: MI1 Floppy: Color cycling in lava cave backwardsSCUMM: MI1 (Floppy) - Color cycling in lava cave backwards

by dwatteau, 2 years ago

Attachment: SAVEGAME._B_ added

DOS savegame with OK lava (English VGA floppy version)

comment:7 by GermanTribun, 2 years ago

I have to add when I reported this bug, the save file was a little older. Has anyone played through the game to that point with a more recent version of ScummVM to see if the bug still occurs? (If not, I'll do so myself)

comment:8 by dwatteau, 2 years ago

Thanks for finding this! :)

I added a new savegame because yours was from the German version, so having one from the (more common) English version could help studying this.

So yeah, it looks like this is a ScummVM-only bug which is still there as of ScummVM 2.6.0git. The lava is fine in the original interpreter.

An easy way to test this is to go to room 65 with the debugger, or use the 999 boot param and go back to the left.

I'm studying the code to see if I can provide a fix for this… no promise, but once you've seen it, you want to fix it ;)

comment:9 by GermanTribun, 2 years ago

Yes, the weird thing is, it doesn't happen in the CD version of the game. Maybe by comparing code you can find out what is happening?

comment:10 by dwatteau, 2 years ago

It looks like it's the same effect between the floppy and CD versions, but the floppy version "encoded" it differently and we may have an incorrect interpretation for that one.

room.cpp has this:

ptr = findResourceData(MKTAG('C','Y','C','L'), roomptr);

If I work from there when _roomResource == 65, I think this is the CYCL data we can find for this room:


(lldb) x/64xb ptr
0x1207b8018: 0x00 0x00 0x34 0x37 0x00 0x00 0x60 0x6b
0x1207b8020: 0x00 0x00 0x70 0x7f 0x00 0x00 0x97 0x9f
0x1207b8028: 0x00 0x00 0x85 0x8f 0x00 0x00 0xa0 0xaf
0x1207b8030: 0x00 0x00 0x49 0x4f 0x00 0x00 0x29 0x2f
0x1207b8038: 0x02 0x64 0xc0 0xc6 0x06 0x99 0xb0 0xbf
0x1207b8040: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x1207b8048: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x1207b8050: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00


(lldb) x/19xb ptr
0x11013801e: 0x01 0x0a 0x70 0x02 0x64 0x00 0x00 0xc0
0x110138026: 0xc6 0x02 0x1c 0x00 0x06 0x99 0x00 0x00
0x11013802e: 0xb0 0xbf 0x00

which I tried to quickly decode this way:


[ 8]: delay=00026, flags=00002, start=192, end=198
[ 9]: delay=00009, flags=00002, start=176, end=191


[ 1]: delay=00026, flags=00000, start=192, end=198
[ 2]: delay=00009, flags=00000, start=176, end=191

i.e. same content between the floppy and CD VGA releases, but the floppy version uses GF_SMALL_HEADER so we decode it a bit differently:

where flags = 2 is something that we hardcode ourselves (and it looks like it's been this way for a long time; I could reproduce the same bug with ScummVM 1.4.0 from 2011 for example).

In palette.cpp, there are some cycl->flags & 2 checks to see in which direction the color cycling should go (if I'm interpreting this correctly).

Maybe that hardcoding flags to 2 for GF_SMALL_HEADER games is wrong (at least for this game and variant), but it takes a lava-flowing-down effect to visually notice that we've been playing color cycling in reverse for some games?

If I apply this quick'n'dirty diff, the lava appears to match the DOS version again:

diff --git a/engines/scumm/palette.cpp b/engines/scumm/palette.cpp
index 190f0b25414..d30c58e70b8 100644
--- a/engines/scumm/palette.cpp
+++ b/engines/scumm/palette.cpp
@@ -583,7 +583,7 @@ void ScummEngine::initCycl(const byte *ptr) {
                        cycl->counter = 0;
                        cycl->delay = 16384 / delay;
-                       cycl->flags = 2;
+                       cycl->flags = ( == GID_MONKEY_VGA) ? 0 : 2;
                        cycl->start = start;
                        cycl->end = end;

but I haven't tested the full floppy VGA version with this change. It's maybe always cycl->flags = 0; for GF_SMALL_HEADER games, actually -- no idea.

I think we'll maybe need some help from someone having the disams for the GF_SMALL_HEADER games :)

comment:11 by GermanTribun, 2 years ago

I quickly checked other SCUMM games again (Indy3 VGA, MI2 and Indy4 Floppy+CD). In all of those color cycling works as intended, so it has to be something specific to MI1 Floppy that ScummVM breaks, most likely something used when the game was reworked for VGA that no other game got (and was later corrected in the CD version).

Sadly, I can't contribute more than observations.

comment:12 by dwatteau, 2 years ago

Thanks for your tests!

Here's some context I found as for when the GF_SMALL_HEADER code above was added:

Indeed, the only places in MONKEY1-FLOPPY-VGA where I could find color-cycling animations are:

  • room 39 (flowing lava, currently backwards; note that the room is randomly generated so this animation only appears in some cases)
  • room 48 (the sign at Meathook's, can't say if it's backwards because I think it just evenly alternates)
  • room 65 (flowing lava, currently backwards).

Loom CD is a GF_SMALL_HEADER game with color-cycling resources, but as the commit above say, they don't really appear to make sense in the game (I believe you can force one if you room 1 in Loom CD for example, but that's not how a real gameplay would display it).

(As for the Amiga version of Monkey1, the lava never flows at all, even with the original interpreter, looking at some YouTube videos.)

comment:13 by GermanTribun, 2 years ago

As I said, I have little idea of the technical side.

MI1 seems to be the first game where color cycling was used more frequently. The EGA games of course didn't have any. Loom only seems to use it for the great loom (maybe also in the EGA version?) but nowhere else, while the only places in Indy3 VGA I can think of are when you rip out the plug in the catacombs and the engine of the zeppelin when taking off by plane (perhaps the lightning at Brunwald also is that?).

Since you already seem to have narrowed it down to the hardcoding, hopefully a solution to this oddity is found.

comment:14 by bluegr, 2 years ago

Owner: set to dwatteau
Resolution: fixed
Status: newclosed

The PR has been merged, so this can be closed now. Thanks for reporting this, and thanks dewatteau for your work on it.

comment:15 by dwatteau, 12 months ago

For reference and future historians, this has been made accurate for v4 Loom CD / Monkey1 CD by AndywinXp in commit 438bdce4542332e8abaf01e160aeea72e26781e4 :)

Note: See TracTickets for help on using tickets.