Opened 3 months ago

Closed 3 months ago

#11544 closed defect (fixed)

SCI: Incorrect palette color in Oracle scene Winged Guard portrait

Reported by: LinkTiger Owned by: sluicebox
Priority: normal Component: Engine: SCI
Keywords: Cc:
Game: King's Quest 6

Description

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)

Attachments (3)

kq6-cd-win.017 (36.3 KB ) - added by LinkTiger 3 months ago.
bug-screenshot.jpg (127.8 KB ) - added by LinkTiger 3 months ago.
Screenshot of erroneous behavior
image-20200801-003820.png (1.3 MB ) - added by OmerMor 3 months ago.

Download all attachments as: .zip

Change History (15)

by LinkTiger, 3 months ago

Attachment: kq6-cd-win.017 added

by LinkTiger, 3 months ago

Attachment: bug-screenshot.jpg added

Screenshot of erroneous behavior

comment:1 by LinkTiger, 3 months ago

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.

comment:2 by ZvikaZ, 3 months ago

Component: --Unset--Engine: SCI
Summary: Incorrect palate color in Oracle scene Winged Guard portraitSCI: Incorrect palate color in Oracle scene Winged Guard portrait

comment:3 by m-kiewitz, 3 months ago

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.

by OmerMor, 3 months ago

Attachment: image-20200801-003820.png added

comment:4 by OmerMor, 3 months ago

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


Last edited 3 months ago by OmerMor (previous) (diff)

comment:5 by sluicebox, 3 months ago

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

comment:6 by sluicebox, 3 months ago

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.

comment:7 by sluicebox, 3 months ago

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.

Last edited 3 months ago by sluicebox (previous) (diff)

comment:8 by m-kiewitz, 3 months ago

Summary: SCI: Incorrect palate color in Oracle scene Winged Guard portraitSCI: Incorrect palette color in Oracle scene Winged Guard portrait

comment:9 by m-kiewitz, 3 months ago

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.

comment:10 by sluicebox, 3 months ago

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.

comment:11 by sluicebox, 3 months ago

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?

comment:12 by sluicebox, 3 months ago

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