aboutsummaryrefslogtreecommitdiff
path: root/engines/titanic/carry/key.cpp
diff options
context:
space:
mode:
authorColin Snover2017-09-24 16:14:53 -0500
committerColin Snover2017-09-24 16:22:40 -0500
commit53dd55ebf215e269142c875b10d9ce854287f5d8 (patch)
tree0f05dec96c2bdf2811506744f08844e1ed0777a8 /engines/titanic/carry/key.cpp
parent56cc138e58b70695d83da890ce6a11ff8148043d (diff)
downloadscummvm-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