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.
These can be big- or little-endian. The development platform can be
autodetected based on RIFX/XFIR in header.
These games ran in Shockwave Player either as a standalone app or as
web browser plugins on Windows and Mac.
Shockwave game added as D6 detection entry as an example.
Catalan and Flemish use existing ISO/locale codes
Arabic uses generic ARB for country code. There is no clear country code
to apply here. We can take ARB to mean Arab League or Modern Standard
Arabic.
TODO: Consult Arabic speakers on country-level dialects
This improves the range of seeds compared to using only getMillis (which
is the number of milliseconds since program start) as the seed. This was
especially an issue if you started the game directly from command line,
Steam, or GOG instead of using the ScummVM interface. Previously the
initial seed was just the load time, which can have very small variance
on a fast computer.
