Files named "PPC" are relatively common for mac games around
the mid-90s (when Apple transitionned from x86 to PPC cpus).
This for example prevent detecting the mac versions of Broken
Sword 1 as unknown director games.
If you ring the boxing bell right at the start of the game, you'll see
Indy hit it 3 times, but the actual bell sound will only be heard twice.
This doesn't happen in the original interpreter or in the other releases
where it can be heard 3 times as expected. Another example is the sound
effect for thunder when Indy is outside the windows of Castle Brunwald;
although it sounds a bit weird this way, the sound is really meant to
have some quick "false starts".
The byte at offset 26 might be responsible for this, in that if it's
unset, the current (identical?) sound is maybe meant to be interrupted.
This is just based on the Indy3 Amiga fixes brought by PR#3598, and
from some naive guesswork. But this change is only applied to Indy3 Mac
and appears to cause no regression (I've done a full gameplay).
Thus, until someone checks this against the original Indy3 Macintosh
interpreter (we have no disasm for it yet), doing this change probably
makes sense for now...
And Andy says I should be more confident about this change :p
Changes the following warnings to errors:
C4701: potential use of uninitialized local variable
C4703: potential use of uninitialized local pointer
C4456: declaration hides previous local declaration
C4003: not enough arguments for function-like macro invocation
C4840: use of non-trivial class as an argument to a variadic function
C4805: unsafe mix of bool and int in a numeric operation or comparison
C4305: truncation of double to float or int to bool
C4366: address taken of unaligned field and used as an aligned pointer
C4315: object constructed into an unaligned field with a constructor that expects it to be aligned
The NDS and AmigaOS ports have frequent buildbot issues, because they
need to use 'long' for int32, for their own reasons. The buildbot is
run *after* things are merged into the main branch, so we'd like to
catch the frequent int/int32 build issues as an earlier development
stage (such as by the automated Github Actions).
MSVC 32-bit builds look like a good candidate for this, since its
'long' is also a 32-bit value on Win32, this platform is tested by
Github Actions right from the PR stage, and there are more developers
doing frequent local build tests there.
Not applying this change to Mingw builds yet, since GCC is less
permissive about this trick (i.e. -Wformat becomes quite noisy), and
the Mingw builds are used for releases, so let's be safe for now.
We already provide ours, and redefining them here this way makes the
build fail with MSVC when building for win32 with 'long' used as the
int32 typedef.
