SCI: Incorrect palette color in Oracle scene Winged Guard portrait

[LinkTiger]

In the King's Quest VI Enhanced edition CD:

In the Oracle's chambers, where you are taken upon completing the catacombs, a Winged One Guard introduces the player to the Oracle. During this introduction, the Guard's portrait appears to use an incorrect palate that paints his hair and eyes bright red.

When this portrait is used in other locations, it appears with the correct colors.

Reproduced on MacOS with both 2.1.2 and the following daily build:
ScummVM 2.2.0git7637-g61cd56009d (Jul 25 2020 05:34:59)
Features compiled in: TAINTED Vorbis FLAC MP3 SEQ TiMidity RGB zLib MPEG2 FluidSynth Theora AAC A/52 FreeType2 FriBiDi JPEG PNG cloud (servers, local)

[LinkTiger]

Screenshot of erroneous behavior

[LinkTiger]

Save file is kq6-cd-win.017. You will have to sit through a couple of scenes before the player is taken to the Oracle and sees the erroneous color.

[m-kiewitz]

Can you please verify if this does not happen when using original interpreter?
A Let's Play video clip of it would be enough, but it has to be one using the original Windows interpreter.

[OmerMor]

Original Windows interpreter appears to be working as intended:
​https://youtu.be/IKUb2vdEq2o?list=PL78472401CE575C47&t=79

[sluicebox]

Great catch! Love how much KQ6 action there is lately. Presumably this is a bug in the RAVE code.

[sluicebox]

This looks like a regression and I bet it's my fault. 2.1.0-release and earlier doesn't have this problem and I've made several changes to palette code to support SCI32 Mac. Those shouldn't have had any affect on a SCI16 PC game but I don't know of any other recent color changes, and this looks like a palette problem, so I probably blew it.

I will now bow my head and do the bisect of shame.

[sluicebox]

Yup, this is a regression from my fix in January for a Hoyle4 palette bug: ​https://github.com/scummvm/scummvm/commit/3de471de36f22c12604d60be16f270c594510a56

This is a bummer, that fix took a lot of work. (I must have patched the script to instantly win the card game?) At a high level, I remember that I correctly identified the problem where ScummVM wasn't doing what SSCI did and addressed it, but I also remember seeing a surprising number of things in the ScummVM code structure that didn't match what was going on in SSCI at all. I hope I just goofed a line but I fear this is just a fix that has exposed another underlying bug or interpreter version difference.

[m-kiewitz]

Doesn't surprise me, if I remember correctly some Hoyle interpreters had special changes not present in regular versions. I was already surprised by this, because I played through KQ6 multiple times to check for any issues years ago.

[sluicebox]

I'm feeling a little less bad after calmly looking at the change and reviewing some old notes.

The issue revolves around palette entry 0. ScummVM's GfxPalette::insert() didn't touch palette entry 0 prior to my change. This broke Hoyle4 because it would palette cycle when winning a hand and then the rest of the game would be stuck with whatever color was in palette entry 0 during the room transition.

That ScummVM mistake is understandable because the common codepath in SSCI excludes palette entry 0, but there's a subtle different codepath, which I remember being complex, that would instead set all the palette entries including 0. That complex codepath wasn't implemented in ScummVM and so I added a condition that would include setting palette 0 when appropriate and exclude it when not.

I'll take a deeper look at this later but I hope that's helpful in getting to the bottom of the discrepancy.

[sluicebox]

I see what's going on. The previous fix didn't go far enough. I'll be running with this fix for a bit to test it further, will probably submit next week.

Funny thing after loading the oracle screen again and again and again... you eventually notice that we've been doing the pic transition backwards for 11 years?

[sluicebox]

Fixed in 43ae2cc2ce89db99cfc00d48a1550fa68c2a6420