#8210 closed patch
EGA LOOM: Hack to fix palette problem
| Reported by: | eriktorbjorn | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Loom |
Description
This is a slightly hacky solution to a Loom palette bug that happens when the dragon finds Rusty. Since Loom doesn't seem to use _currentPalette at all, script_v5.cpp had been modified for 16-colour games so that setDirtyColors() was never called.
However, that meant that changes to the shadow palette went largely unnoticed. This patch changes the behaviour of setDirtyColors() instead so that for 16-colour games it forces a full redraw.
Originally I wanted to change the palette handling instead so that it would work the same way for 16-colour games as for all the other ones, but I couldn't figure out how to get that to work.
I had to make a slight adjustment to descumm3 as well, to get it to handle that particular script.
Ticket imported from: #730800. Ticket imported from: patches/315.
Attachments (4)
Change History (10)
by , 21 years ago
| Attachment: | loom-palette-hack.diff added |
|---|
comment:1 by , 21 years ago
Here's a much more elaborate version, which makes 16-colour games handle the palette in the same way as the more recent games. This is how I originally wanted to do it, but I couldn't figure out how at first.
The things that stumped me:
Since older savegames don't store the palette, we either break those savegames or - like this patch does - make sure the EGA palette is re-initialized every time a savegame is loaded. This is a bit of a hack, but really not so different from what the current version does.
With the new palette handling, the graphics decoder should no longer do the shadow palette remapping. I assume that this also applies to the old EGA decoder.
I've made a few changes that could have been a separate patch:
Similarly to the graphics decoder, I believe the costume renderer shouldn't use the shadow palette for GF_16COLOR games. Or GF_SMALL_HEADER games for that matter, since they handle the shadow palette in the same way. I'm a bit uncertain about this though.
I've added setDirtyColors() to startScene() for GF_SMALL_HEADER games since the function resets the shadow palette. When the rest of the patch is applied, this makes a small but noticeable difference on the red tapestry early in the game.
Issues:
This palette handling introducees a slight ugliness that wasn't there before: During the transition effect at the end of the dragon scene, Rusty the Grey briefly turns into Rusty of Many Colours because we once again use the default palette. According to DOSBox this happens in the original interpreter as well. (The same thing already happens in other games, too.)
Future plans:
Ideally we should only allocate 16 elements for the palette and shadow palette for 16-colour games, but that can wait.
comment:2 by , 21 years ago
Yeah the palette change sadly is "normal". There is not too much we can do about it I fear. Of course if there is first a fade-to-black, followed by a fade-in, we can just delay any palette changes until the screen is black. But for "direct fades", if the old and new screen use different colors, there is not much we can do.
comment:3 by , 21 years ago
| Status: | new → closed |
|---|
comment:4 by , 21 years ago
| Owner: | set to |
|---|
comment:5 by , 21 years ago
This also fixes the colors on the MonkeyEGA copy protection screen (where you have to enter a date; it's now an all-blue background, instead of blue-text-background-rects-on-black).
comment:6 by , 5 years ago
| Component: | → Engine: SCUMM |
|---|---|
| Game: | → Loom |
Patch against an April 30 CVS snapshot