Opened 16 years ago

Closed 16 years ago

Last modified 16 years ago

#1005 closed defect (fixed)

INDY3EGA: Speech text black for one guard in castle

Reported by: SF/quietust Owned by: Kirben
Priority: normal Component: Engine: SCUMM
Keywords: Cc:
Game: Indiana Jones 3


Version used: latest snapshot from website (July 12)

In the Amiga version of INDY3, there is one guard in the
castle whose dialog text is invisible, making it rather
hard to carry on a proper conversation with him (and
avoid getting in a fight).
His location is as follows: 2nd floor, north hallway, to the
right of the security system room. I have attached a

Ticket imported from: #770340. Ticket imported from: bugs/1005.

Attachments (1)

indy3ega.s01 (54.4 KB ) - added by SF/quietust 16 years ago.

Download all attachments as: .zip

Change History (12)

by SF/quietust, 16 years ago

Attachment: indy3ega.s01 added


comment:1 by SF/quietust, 16 years ago

Whoops, forgot to click the checkmark to attach the file

comment:2 by SF/dfabulich, 16 years ago

I have reproduced this issue in the Spanish DOS version as
well. Win2K, ScummVM 0.5.0pre-cvs, Built on Jul 14 2003

comment:3 by SF/dfabulich, 16 years ago

It's also worth pointing out that this issue is pretty
serious. Talking to this guard correctly is the only easy
way to get past Siegfried on the third floor. By giving
this guard conversation options 3 2 3, he tells you that
Siegfried on the third floor has the authorization to see
secret orders. Then, on the third floor, you can use
options 3 2 3 and recognize Siegfried, which gets you past
him. He's a really difficult fighter, and AFAIK this is the
only way to get past him without fighting him.

comment:4 by Kirben, 16 years ago

Summary: INDY3EGA: Amiga - Speech text black for one guard in castleINDY3EGA: Speech text black for one guard in castle

comment:5 by fingolfin, 16 years ago

Odd issue... the problem is there with this particular guard
because for it, a->talkColor is set to 13. If I override that to be
any other value, it works fine. The palette entry for color 13 is
correct, too. Proof: If I use the RGB values for entry 13 in any
other entry, that works fine; similar, if I use the RGB value of any
other entry for color 13, the text still doesn't appear

I know that color 13 is used as a masking color in akos.cpp and
bomp.cpp. However neither is used for a V3 game.

The charset renderer is being called, BTW (the guard says 'hmm -
do you want something').

comment:6 by fingolfin, 16 years ago

Ah the problem is that, while the Scumm palette entry 13 is
correct, in the SDL backend palette it is not... updatePalette() sets
it to black (RGB 0,0,0). That is so because of _shadowPalette, in
particular, _shadowPalette[13] == 0. Indeed, subop 2 (room
color) of o5_roomOps is called twice when entering the room with
that guard:
_shadowPalette[5] = 4
_shadowPalette[13] = 0

So, obviously we do something wrong with regards to that opcode
(as if we didn't already know, see also the big FIXME in
script_v5.cpp, line 1659).

comment:7 by fingolfin, 16 years ago

This is caused by the entry script of room 23, which has these two

[031A] (33) RoomColor(4,5)
[0320] (33) RoomColor(0,13)
This is only done in case Var[4] == 154 (Var[4] is VAR_ROOM),
and indeed this occurs in room 154/23 (154 is _currentRoom, 23 is

I think I understand now why this appears wrong in ScummVM: we
handle _shadowPalette incorrect for GF_SMALL_HEADER games. In
Scumm::updatePalette, it is used to affect the *whole* game
graphics. This is wrong: it should only affect object+room
graphics. It should *not* affect text output, and probably not
actors either.

comment:8 by SF/quietust, 16 years ago

I've got a few more examples of bad text colors. See the
maps at the following URLs for locations:

In all cases, inventory items *should* be displayed with
purple text.

Floor 1:

* Tapestry: Inventory items showing up bright blue (dark blue
* Empty 1: Inventory items showing up dark blue.
* Drunk: Inventory items showing up teal. The bubbles above
the drunk soldier's head are also showing up teal instead of
* Empty 2: Inventory items showing up dark red.
* Empty 3: Inventory items showing up dark green.
* Empty 4: Inventory items showing up bright red (dark red

comment:9 by SF/quietust, 16 years ago

In any event, it looks like those problems are coming from the
fact that all of those rooms use a 'default' room graphic with
a purple rug (with magenta trim), and the color changes (to
make the rug a different color) are getting applied to too

In other words, you appear to be correct in your assumption
that RoomColor() should only affect the room itself, not

comment:10 by Kirben, 16 years ago

Fixed in latest ScummVM cvs.

comment:11 by Kirben, 16 years ago

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