The 16-bit DPCM decompressors in SSCI and Urban Runner use a 16-bit
register to store sample data, without any special handling of
overflow. As such, out-of-range samples simply wrap around, rather
than getting clipped.
It is not totally clear if the wrapping behaviour was intentionally
exploited to handle extreme transients, but in any case, videos
like GK2 5280.VMD that generate samples outside the signed 16-bit
range cause a loud pop when using clipping, but play back correctly
when wrapping.
In SSCI, VMD is drawn by a standard CelObjMem wrapped by a
ScreenItem, giving the location of the bitmap memory to the
decoder. The decoder already supports this, but the API was
previously hidden behind the AdvancedVMDDecoder wrapper
(which is more convenient to use than the VMDDecoder class).
After discussing with DrMcCoy, we felt this the best way to proceed. A wrapper class that implements AdvancedVideoDecoder is still around for use in SCI.
This is a workaround for how Lost in Time behaves in combination
with changes I made to the DataIO code for running Urban Runner
on low-memory devices.
Urban Runner's intro are far to big to have them copied into
memory for these devices, so I made the DataIO code return a
SafeSeekableSubReadStream into the opened archive stream instead.
Unfortunately, Lost in Time might not close a video file when it
closes the data file which it was originally in, especially when
loading a saved game. Since the video player needs to be able to
gaplessly continue a video and there does not, by itself, close
the video if not requested by the scripts, this leads to reading
out of an already closed stream in certain cases.
So, to worka round this issues, the video player tries to reopen
each currently opened video after a data archive was closed, to
make sure that that video is still available. If not, the video
is closed.
Certain codecs seem to use a Surface with Bpp 2, but do not have any proper
format description. Whoever is maintaining these should check this commit and
fix the format properly.
MKID_BE relied on unspecified behavior of the C++ compiler,
and as such was always a bit unsafe. The new MKTAG macro
is slightly less elegant, but does no longer depend on the
behavior of the compiler.
Inspired by FFmpeg, which has an almost identical macro.
When decompressing directly onto the output surface fails (because
it's too small), retry decompressing into the video buffer first,
which then gets blitted onto the output surface.
The Inca 2 video where Atahualpa walks through the gate after
solving the wisdom challenge now only warns (and graphically
glitches) instead of segfaulting.