In AGS there is a possibility to define a function, FileCloseNotify
with arguments, which is called when closing a file. This possibility
seems not to be used by any of the engines supported by ScummVM since
it's set to nullptr. This is not a problem in itself. Hoewever when
enabling compiler optimisiations the compiler may optimise away the
FileCloseNotify definition. This was discovered when compiling iOS
with Apple Clang in "Release" mode that the if-case in the code block
below was removed while the args parameter was left:
if (FileCloseNotify) {
CloseNotifyArgs args;
args.Filepath = _fileName;
args.WorkMode = _workMode;
FileCloseNotify(args);
}
This caused a nullptr exception since FileCloseNotify was nullptr.
A bit strange behavior by the compiler which could remove the entire
code block above.
Since the FileCloseNotify is not used in ScummVM, remove it as it
only seems to be used in upstream by the emscripten code which is
not part of the ScummVM repository.
Screen limits are hardcoded in ScummVM's implementation, so this function
does not really validate anything
Partially from upstream cbe729f93c9b204db41ddd1b28c455d4a98ff703
- with FileStream::FileCloseNotify we can run an event when a file closes
- the arguments are a struct so we can expand them later if needed easily
From upstream 2c170cacb84f56004d86d8e981710777c9c09554
This somewhat reverts 2b9f130 , while keeping tidier code and safer args.
Switching from lzwexpand_to_mem to using streams only caused speed
regression, which became notable for hi-res games with LZW sprite
compression (a 3.6.0 feature).
For this revert we instead load compressed data into a buffer in whole,
then pass two memory buffer pointers to lzw_expand, where it reads
and writes memory directly.
Testing a high-res (1920x1080) game with lots of sprite streaming
showed speed improvement of this function by around 200%.
The downside is the temporary buffer for reading compressed
data too.
In theory, same could be done for lzwcompress afterwards.
From upstream 6959004676916568c6fca210702d669f61741e13
As the cursor is always at the end of the stream, BufferedStream::EOS()
always return true.
We check for errors when writing so no check is needed here.
Apparently, this was already done once in b6b8701, but then broken soon after by a merge 22e3a83 (years ago).
From upstream 50800e0e2aca0b7678af4a24bd6322d82261760f
There have been this stupid oversight all along since the introduction
of the class: while it reported Length and EOS correctly, it still
allowed to read past the end.
This can cause issues if the user code relies, for example, on Read()
or ReadByte() return value.
For upstream code, in practice this fixes MP3 streaming, where the length
of data is not always possible to precalculate. In ScummVM we used a
different code for MP3, but this may fix other cases as well.
From upstream 6f02bedc65b902ce41858b7e92970662020a11cf
Fixes kq1agdi crashing on big-endian systems, since it tried to allocate
a gigantic amount of memory from MFLUtil::ReadV21() because of the
misread values.
From upstream 5e29a339fc83bf5c06a3a9a3b1c65a2fc4b4e72c
Also includes upstream 427752da015fd93549deef1a31d5e533e5c9319e
Part of upstream 82a928cb07970acc5918905c5836c39ce11b7f32
(Tests: added BufferedStream tests)
This commit has no functional change but allows to keep the code
in ScummVM close to upstream code.
Walter Agazzi
Le Philousophe
Lars Sundström
D G Turner
Thierry Crozat
Vladimir Serbinenko
Hubert Maier
Donovan Watteau
Paul Gilbert