#8002 closed patch
Possible fix for bug #558711
| Reported by: | eriktorbjorn | Owned by: | SF/ender |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
I think the problem reported in bug #558711 is in o5_roomOps()'s "set palette color". In the GF_SMALL_HEADER case, it will manipulate _shadowPalette, which just won't do anything noticeable here.
I have two experimental patches which both seem to do the trick, albeit in different ways.
greatloom.diff sticks with the current _shadowPalette solution, and changes updatePalette() to take this into consideration if it's running a GF_SMALL_HEADER game. Note that it now says _shadowPalette[b] = a instead of _shadowPalette[a] = b. This is intentional. The animation would be wrong otherwise, and colours that shouldn't be remapped are.
greatloom2.diff adds a "backup" palette which stores a copy of the current palette as it was first loaded, and then uses setPalColor() to modify the current palette.
I think greatloom.diff is probably the better solution, assuming it doesn't break anything else. Since Loom is the only GF_SMALL_HEADER game that I own, and I haven't gotten very far into it yet, I can't test this.
Ticket imported from: #591581. Ticket imported from: patches/107.
Attachments (3)
Change History (7)
by , 22 years ago
| Attachment: | greatloom.diff added |
|---|
by , 22 years ago
| Attachment: | greatloom.gif added |
|---|
This is what the "great loom" animation will look like
comment:1 by , 22 years ago
I forgot to mention that the patches were made against an August 4 CVS snapshot.
comment:2 by , 22 years ago
| Owner: | set to |
|---|---|
| Status: | new → closed |
comment:3 by , 22 years ago
I've applied the first one, after some testing... it appears to work on a few small_header games without breaking anything.
Excellent work, thanks :)
comment:4 by , 5 years ago
| Component: | → Engine: SCUMM |
|---|
Patch which uses _shadowPalette