| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Videos in GK2 use this flag (e.g. the chapter 6 intro).
Now that GfxPalette32::updateHardware no longer calls
OSystem::updateScreen (only GfxFrameout::frameOut does this now),
every time a palette swap occurs during playback, there is a frame
of blackness that should not exist. This is because the order of
operation is:
1. Send black palette
2. Call frameOut (which updates the screen)
3. Send new, correct palette
4. No frameOut (so the screen is not updated with the correct
palette)
OSystem::updateScreen cannot be called multiple times for the same
frame due to vsync, but also, there does not appear to be any
reason to send a black palette, since it seems to be intended to
avoid temporarily rendering video frames with the wrong palette on
a hardware device that cannot guarantee simultaneous application
of a new palette and new pixel data. ScummVM does not have such
a problem, so this feature appears to be unnecessary for us.
For the moment, this 'feature' remains hidden behind an ifdef,
instead of being removed entirely, to avoid potential confusion
when comparing VMD code from SSCI.
|
|
|
|
This was causing uninitialised garbage data from the scale buffer
to be drawn to the screen.
|
|
|
|
Used by RAMA, when playing a video at the Hub Camp computer at the
beginning of the game (room 1004).
|
|
The boost is intended to compensate for the darkness caused by the
black lines, so should not be applied when there are no black
lines. This fixes too-bright videos in at least LSL7.
|
|
In at least RAMA, when using the pocket computer to view a mail
and then pressing the "return" button, the ScreenItem containing
the VMD will be destroyed before the VMD player is told to close
the video, resulting in a use-after-free trying to access the
bitmap ID through the deleted ScreenItem.
|
|
|
|
|
|
GK2 includes some VMDs in the RESSCI.00n volume bundles for the
chase scene at the end of Chapter 6.
|
|
Fixes Trac#9662.
|
|
|
|
Used in Shivers room 35170 when pressing the play button.
|
|
|
|
For example, Shivers room 932 when subtitles are enabled.
|
|
Fixes Trac#9588.
|
|
|
|
|
|
|
|
Used only by chapter 7 of Phant1.
|
|
CID 1361588.
|
|
The sleep values for video playback are the amount of time until
the next frame needs to be displayed, whereas speedThrottler is
used to ensure that a given amount of time always elapses between
two triggered speedThrottler calls.
|
|
|
|
Used by Lighthouse.
|
|
|
|
Drawing the cursor in this mode will result in a read overflow as
it is 8bpp.
|
|
|
|
|
|
|
|
|
|
|
|
There is still a problem where the background is white instead
of black; this is caused by the palette of the video using entry
0 as white. This seems to have worked out OK in SSCI because the
video was not actually played back inside the engine itself, so
didn't interfere with the palette of the engine. ScummVM has no
such separation, so the palette of the video interferes with the
palette of the blank background pic, turning it white.
|
|
|
|
Revert "SCI32: Fix KQ7 1.51 video background"
This reverts commit c8affb54cca259f37522216bad739be085bf9caa.
Revert "SCI32: Fix crash when kShowMovie is called but the video cannot be found"
This reverts commit 93b06f4a9e08de281ee7eb9c780ceac147c3fb23.
Revert "SCI32: Fix KQ7 1.51 basic video playback"
This reverts commit cdab24aa07c18ad4a25a1659f7fca15cca5e358e.
Revert "SCI32: Additional Video32 documentation"
This reverts commit 4ff0924e57a9bc9101ee0799a967fe3373dd2574.
Revert "SCI32: Implement kShowMovie"
This reverts commit 13297c19298c5ad73c9e996c5c31ca91de124911.
|
|
|
|
|
|
There is still a problem where the background is white instead
of black; this is caused by the palette of the video using entry
0 as white. This seems to have worked out OK in SSCI because the
video was not actually played back inside the engine itself, so
didn't interfere with the palette of the engine. ScummVM has no
such separation, so the palette of the video interferes with the
palette of the blank background pic, turning it white.
|
|
|
|
|
|
Bitmaps in ScrollWindow and Robot code are managed by the kernel
and not by game scripts, although they must be able to be
referenced through a reg_t. To prevent incorrect GC of bitmaps
that are in use but not referenced by any game script, explicit
memory management of hunk entries can be enabled.
|
|
|
|
|
|
Ow. My eyeballs.
|
|
|
