Opened 7 years ago
Closed 7 years ago
#9843 closed defect (fixed)
SCI: KQ7 Win ES: White is drawn as black in videos
Reported by: | Bakhtosh | Owned by: | csnover |
---|---|---|---|
Priority: | blocker | Component: | Engine: SCI |
Version: | Keywords: | sci32 | |
Cc: | Game: | King's Quest 7 |
Description
ScummVM Version: 1.10.0git3459-g9bb9c0d58e (June 13 2017 19:25:33)
OS: Windows 10 x64
Game version: King's Quest 7 v2.00 CD/Windows/Spanish
The problem seems to be similar to #9762. Only that this happens with the spanish Windows version v2.00 (instead of with the english Windows version 2.00b).
The .avi files used for the game's videos in the Windows version are not being shown correctly. If you don't switch the cutscene size to full the only about a quarter of each frame is displayed. Apart from that areas which should be white are shown as black instead (palette problem). See attached screenshots. If you switch the cutscene size to full the full frames are displayed. But the described color problem is still present.
sidenote: The .rbt videos used by the spanish DOS version v2.00 are played fine.
Attachments (2)
Change History (7)
by , 7 years ago
Attachment: | scummvm00014.png added |
---|
by , 7 years ago
Attachment: | scummvm00021.png added |
---|
comment:1 by , 7 years ago
comment:2 by , 7 years ago
Summary: | SCI: KQ7: spanish Windows version: cutscenes: only snipped displayed / wrong palette → SCI: KQ7 Win ES: White is drawn as black in videos |
---|
Thanks for your report! The KQ7 videos in CRAM format are encoded with palette entry 0 as white, which conflicts with the SCI palette where entry 0 is black. This worked in the original interpreter because the videos were actually rendered outside the SCI process using MCI, so the different palettes did not conflict. In ScummVM, we render the videos to the same surface as the rest of SCI for simplicity’s sake, so the black & white palette entries cannot conflict as they do here.
There is already a workaround in ScummVM that fixes the problem in KQ7 1.x by remapping these pixels; this workaround just was not applied to 2.00b because that (English) version of the game used Cinepak, so it did not seem to be relevant. To fix this bug, this workaround just needs to be improved with a better criteria, like actually looking at the video data instead of just assuming the palette needs fixing based on the interpreter version.
The other problem mentioned in this ticket regarding the incorrect video dimensions is the same bug as #9762, so please watch there for updates on that bug.
comment:3 by , 7 years ago
Things is I can't reproduce #9762 anymore with 1.10.0git3459-g9bb9c0d58e (June 13 2017 19:25:33).
If I play the english Windows version v2.00b with this ScummVM build everything is fine. No wrong color and no wrong dimensions (Movie size half & full).
I've added the english Windows version v1.65c and english Windows Version v2.00b to ScummVM and for me it's like that with the mentioned ScummVM build:
- ScummVM + english Windows version v1.65c + CRAM AVI's (normal config) => everything is fine (colors and dimensions ok for Movie Size half & full)
- ScummVM + english Windows version v2.00b + Cinepak AVI's (normal config) => everything is fine (colors and dimensions ok fpr Movie Size half & full)
- ScummVM + english Windows version v1.65c + Cinepak AVI's => colors and dimensions ok for Movie Size half, colors ok but the video isn't scaled up and shown at the left side of the screen/window (whole frame)
- ScummVM + english Windows version v2.00b + CRAM AVI's => wrong colors and only the upper left quarter of each frame is shown for Movie Size half, wrong colors and the video is scaled up but with wrong aspect ratio (a bit too high)
Can you still reproduce #9762 with a current build?
My english Windows version v2.00b is from the Kings Quest Collection series.
The behaviour of the spanish Windows version v2.00 with ScummVM is similar to
"ScummVM + english Windows version v2.00b + CRAM AVI's"
comment:4 by , 7 years ago
Priority: | normal → blocker |
---|
comment:5 by , 7 years ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Thanks for your report! A fix for this problem has been added in commit 8cb35442c073b5ed5a0f3fa7d5e627bdd85af229 and will be available in daily builds 1.10.0git-3728 and higher.
Can you still reproduce #9762 with a current build?
I was actually not ever able to reproduce that bug, though I had remembered seeing something like it once or twice in the past. In any case, all the AVI rendering code has been refactored so it should not be possible to end up in a situation where rendering gets clipped like that any more.
I noticed a few things that may be helpful:
The english Windows versions v1.51/v1.65 are using .avi's with codec Microsoft Video 1 (CRAM) 8 Bit palettized while the english Windows version v2.00b is using .avi's with codec Cinpak video. My guess is that this caused #9762 (wrong codec expected). I can't reproduce #9762 anymore. So to me it seems that this issue has been fixed (even if the issue is still open).
The spanish Windows version v2.00 is using .avi's with codec Microsoft Video 1 (CRAM) 8 Bit palettized. My guess is that the spanish Windows version 2.00 is treated (from the video point of view) like the english Windows version v2.00b. And that this causes this issue (wrong codec expected - just the other way around).
If I copy the spanish avi's into the english Windows version v1.65 and run this version the videos are displayed correctly. This kind of supports my guess I think.