diff options
author | Colin Snover | 2017-09-24 16:14:53 -0500 |
---|---|---|
committer | Colin Snover | 2017-09-24 16:22:40 -0500 |
commit | 53dd55ebf215e269142c875b10d9ce854287f5d8 (patch) | |
tree | 0f05dec96c2bdf2811506744f08844e1ed0777a8 /engines/titanic/carry/key.cpp | |
parent | 56cc138e58b70695d83da890ce6a11ff8148043d (diff) | |
download | scummvm-rg350-53dd55ebf215e269142c875b10d9ce854287f5d8.tar.gz scummvm-rg350-53dd55ebf215e269142c875b10d9ce854287f5d8.tar.bz2 scummvm-rg350-53dd55ebf215e269142c875b10d9ce854287f5d8.zip |
SCI32: Fix bad palettes in Lighthouse when HQ video is enabled
In a couple of places, Lighthouse updates the renderer with screen
items for the next room before the room transition video plays.
This is normally fine when using the compositing video renderer
because the videos are drawn into new planes which occlude the
screen items, so the screen items are culled from the draw list
and do not submit their palettes. However, when in HQ video mode,
we currently force the overlay renderer, which was not blocking
screen items before forcing a frameOut, so the screen items'
palettes got submitted prematurely in this case and caused bad
rendering after the video finished playback.
Now, if we are forcing into the overlay code path, we still create
a blank plane behind the overlay before the forced frameOut in
order to correctly occlude screen items and keep them from
participating in rendering before they normally would.
Fixes Trac#10233, Trac#10235.
Diffstat (limited to 'engines/titanic/carry/key.cpp')
0 files changed, 0 insertions, 0 deletions