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

[GermanTribun]

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.

[Mataniko]

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

[GermanTribun]

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).

[bonki]

Do you happen to have an original engine savegame?

[GermanTribun]

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.

[dwatteau]

DOS savegame with OK lava (English VGA floppy version)

[GermanTribun]

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)

[dwatteau]

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 ;)

[GermanTribun]

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?

[dwatteau]

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:

MONKEY1-FLOPPY-VGA:
-------------------

(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

MONKEY1-CD:
-----------

(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:

MONKEY1-FLOPPY-VGA:
-------------------

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

MONKEY1-CD:
-----------

[ 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:
<​https://github.com/scummvm/scummvm/blob/97a138ae2e51e357d93e2eb689ad797338fae4fb/engines/scumm/palette.cpp#L573>

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 = (_game.id == 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 :)

[GermanTribun]

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.

[dwatteau]

Thanks for your tests!

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

https://bugs.scummvm.org/ticket/1016
​https://github.com/scummvm/scummvm/commit/cec02390ed9b068bb12c3ab03b0d92c7c70d8c4f

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.)

[GermanTribun]

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.

[bluegr]

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

[dwatteau]

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