libsmacker: allow overlapping copies in the 0x40 palette opcode

The color-shift opcode copies a run of palette entries from the previous
frame's palette to the current one. libsmacker rejected the copy when the
source and destination ranges overlapped, aborting the whole palette decode
and leaving the palette half-updated -- so every frame from the first such
opcode on rendered with a mix of the new and stale palette.

The overlap check is bogus: the copy reads from oldPalette, a snapshot taken
at the top of the function, and writes into s->palette, a separate buffer, so
overlapping ranges are harmless (and it is a memmove regardless). ffmpeg and
the original SMACKW32.DLL have no such check.

Several of the videos that ship with the game (Rebel_cr, Omerta, Prague) use
these overlapping copies, and showed washed-out colours with the previous
frame's palette bleeding through. Drop the overlap clause, keep the real
256-entry bounds checks.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Marco Antonio J. Costa
2026-07-23 19:01:37 -03:00
committed by majcosta
co-authored by Claude Opus 4.8
parent 4ff2853b70
commit 83b637aa73
+4 -3
View File
@@ -1224,9 +1224,10 @@ static char smk_render_palette(struct smk_video_t * s, unsigned char * p, unsign
p ++;
size --;
/* overflow: see if we write/read beyond 256colors, or overwrite own palette */
if (i + count > 256 || src + count > 256 ||
(src < i && src + count > i)) {
/* overflow: see if we write/read beyond 256 colors. Overlap between
the src and dst ranges is fine: src reads from oldPalette, a
snapshot taken above, while we write into s->palette. */
if (i + count > 256 || src + count > 256) {
fprintf(stderr, "libsmacker::palette_render(s,p,size) - ERROR: overflow, 0x40 attempt to copy %d entries from %d to %d\n", count, src, i);
goto error;
}