Apple's desktop operating system was formerly called "Mac OS X" and "OS X", but since 2016 it has been called "macOS" (starting with version 10.12).
Changing across all comments and documentation to use this current terminology, except in cases where the historical versions are explicitly referenced. No code changes are made; we should consider changing those in future PRs.
The pos() method of BufferedWriteStream should return the stream position
but actually returns the buffer position. That completely breaks saving
the game in AGS engine on the platforms using BufferedWriteStream wrapper
for savefile handling, such as Nintendo Switch. AGS engine's save file
writing functions use GetPosition() with later Seek() on stream,
so an invalid return value from GetPosition() results in invalid save files
that cannot be loaded and are skipped by the engine.
This platform was supported by Sierra for early and pri-AGI games.
CoCo 1 and 2 were not generally forward compatible with CoCo 3,
which was officially supported by Sierra for KQ3 and LSL1 only.
The parsing was rather lazy and would e. g. find "ega" in "midiSegaCD", so that the launcher offered me an "EGA" rendering mode for EOB SegaCD. Now, there is less lenience, but ScummVM will always write the string in the correct format anyway...
Mostly done using the following Ruby script:
(Dir.glob('**/*.cpp') + Dir.glob('**/*.h')).each do |file|
s = File.read(file, encoding: 'iso8859-1')
t = s.gsub(/(([\w_.\[\]]+)\s*=\s*new\s+\S+?\[[^\]]+?\](?!\())([^\{\}]*?)\n\s+memset\(\s*\2\s*,\s*0\s*,[^;]*;/m, '\1()\3')
if t != s
File.open(file, 'w') { |io| io.write(t) }
end
end
The old RNG method had non-standard periods, ranging from some seeds looping on themselves (seed = 1184201285) to some seeds having periods as low as 11 or 48, as listed in https://github.com/scummvm/scummvm/pull/3340. This is a problem even for games that run the RNG once a frame, as the possibilities for random events is greatly reduced should the initial seed be in one of these sets of small periods.
Xorshift* is a standard, fast, non-cryptographic PRNG with academic backing that has period 2^32-1 (all seeds lead to another seed except 0, which is excluded from the initial seeds). Many different flavors are possible, as listed in the paper, but the choice implemented in this pull request uses only a single 32-bit integer as a state, like the old PRNG.
Co-authored-by: Thierry Crozat <criezy@scummvm.org>
Co-authored-by: Filippos Karapetis <bluegr@gmail.com>
Previously the file format had all chunks, offsets and values stored in
little-endian format. The one exception was screenshots, which used the
existing THMB code in graphics/thumbnail.cpp, that is entirely
big-endian. Any tooling which attempts to parse the Event Recorder file
format must make a special exception for THMB chunks, and read the chunk
size and contents as big-endian.
In the interests of making the file format more consistant
to parse, and given that backwards compatibility is not required for
this iteration of Event Recorder, this patch changes everything to
big-endian.
Screen update boundaries are now used as sync points.
Screenshots are now processed on a screen update boundary.
This change increments the version of the Event Recorder
file format to 2; version 1 files will still play back as
before, without synchronising to screen updates.
If there is a file handle, the clear() method checks if it should be
disposed of. However, the _disposeFileHandle variable was never set, so
it's unlikely that _exe was ever deleted. I found this out from a
Valgrind warning when quitting Buried in Time.
This seems like a very obvious fix to me, and as such it seems like a
good candidate for backporting to the release branch. On the other hand,
maybe there are cases where it worked by sheer, dumb luck? I'm not
familiar enough with where and how it is used.
When running my CD version of Buried in Time, the loadFromCompresedEXE()
function would try to decompress beyond the allocated buffer, causing it
to crash. Up to that point, the decompressed data was identical to what
I would get if I let the original installer decompress the EXE and DLL
files.
So keep track of how many bytes have been decompressed, and terminate
when the upper limit is reached.
