#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 |
| Version: | Keywords: | ||
| Cc: | Game: | Indiana Jones 3 |
Description
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 savegame.
Ticket imported from: #770340. Ticket imported from: bugs/1005.
Attachments (1)
Change History (12)
by , 21 years ago
| Attachment: | indy3ega.s01 added |
|---|
comment:2 by , 21 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 03:24:03.
comment:3 by , 21 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 , 21 years ago
| Summary: | INDY3EGA: Amiga - Speech text black for one guard in castle → INDY3EGA: Speech text black for one guard in castle |
|---|
comment:5 by , 21 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 , 21 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 , 21 years ago
This is caused by the entry script of room 23, which has these two lines:
[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 _roomResource).
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 , 21 years ago
I've got a few more examples of bad text colors. See the maps at the following URLs for locations:
http://qmt.ath.cx/~quietust/scumm/castle_1.png
In all cases, inventory items *should* be displayed with purple text.
Floor 1:
* Tapestry: Inventory items showing up bright blue (dark blue highlight). * 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 purple. * 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 highlight).
comment:9 by , 21 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 much.
In other words, you appear to be correct in your assumption that RoomColor() should only affect the room itself, not text/actors.
comment:11 by , 21 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Savegame