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
(Monkey 1 EGA / CMS music and sound effects dissapear after loading saved game)
This is at least one obvious bug which I found. For CMS sound the sound resources get invalidated after one use which is only supposed to happen if the resource cannot be loaded.
MI1 also has other issues with CMS sound if the user changes the sound setting between savegames. The savegames are not compatible. But that is a more complex thing to fix and might not be related to the bug ticket.
Also, we might need to restore sounds that were currently playing at the time of saving (but I have to check if the original actually does that for CMS).
This replaces every single strcpy call in the engine with
Common::strlcpy.
Some of these might cases seem a bit pointless, but it is
supposed to discourage future use of strcpy. If people don't
see a single occasion of it they might think twice before they
use it...
Target is partly dysfunctional. Savegames can still be loaded from GMM, but the game will abort at the difficulty select dialog when starting normally...
When ripping the audio tracks from CD, you may not get quite what the
game expects, e.g. my copy of Loom has less silence at the start of the
track than the CDDA.SOU file from the Steam version. And the MI1 intro
appears to be timed with the assumption that there is no silence at all
at the start of that track.
This makes it possible to compensate for that without having to edit the
audio file. It may also be of some help with fan soundtrack replacements
for MI1, though I have little experience with that.
Now that VAR_TIMER_TOTAL is reliable, use that for timing the Loom
replacement audio tracks instead. This saves us the bother of handling
pausing and things like that.
I think it should work even with older savegames, but at the moment
resuming the track from where it was saved isn't working for me. It
seems to be doing the right ting, but then the track gets restarted.
This may be because of recent changes to Loom save/restore?
LucasArts released (at least) an official Japanese version with Japanese
text and English voices; plus, there are some fan-made translations made
for the original English Talkie version. They appear to use the same
MONSTER.SOU (or INDY4.SOU) file.
So, instead of only applying the Trac#10559 workaround to Common::EN_ANY
releases, accept any (talkie) version, as long as we can find the broken
VOC header at that offset.
Don't try to update the _musicTimer in saveLoadWithSerializer(), because
we haven't yet loaded all of the savegame. Instead, do that in a new
restoreAfterLoad() method.
As an extra bonus, if an audio track was playing when the game was
saved, try to resume it from approximately that point.
Unfortunately, it turns out that _currentCDSound was not properly reset
when the song ended so loading a savegame made with an earlier version
of this feature may cause it to play music that it shouldn't. But that's
the kind of thing you should count on on the bleeding edge. Savegames
made after this change should be fine.
Before, the music timer was based on the number of SCUMM ticks that had
passed since the track started. But this meant that the timing could
differ by several seconds depending on your hardware.
Now it's instead based on the amount of time that has passed since the
replacement track started playing. Time that passes while the game is
paused does not count. Of course, if the player suspends the process that
time still counts. But the player was clearly asking for it then!
Would it be better to tie it to the current position in the audio track?
Possibly, but the CD audio manager doesn't provide that information.
Even if it did, the timer has to run even if the track ends prematurely,
because we can't just assume that every available recording has the
expected length.
But at least, we now have a well defined unit of measurement: We
hard-code the point in time where the Overture transition should happen
with the Ozawa recording. Ten ticks on the settings slider moves this
point by one second, allowing the user to adjust it by 20 seconds in
each direction. Surely that should be enough?
It's hard to make this appear only on EGA Loom, so the tooltip has to
document the fact that it's only useful there. The setting is made
relative to the default tempo, which I feel is a much more sensible way
of presenting it to the user than the raw ticks value.
I can only conclude that SCUMM ticks aren't accurate enough to match the
original timer, but at least the transition now happens almost at the
same point as with the MT-32 version, when using the Ozawa version of
the music. Maybe this should be configurable, to accommodate for
different recordings?
I mistakenly thought they should be looped, but after testing (both with
ScummVM and DOSBox) I have come to the conclusion that they should not.
The music ends whenever there is a sound effect anyway, so having the
music play to the end of the track is the exception, not the rule.
In the FM Towns version, music does play continuously. Personally I find
this makes the game much harder, since the music can drown out the sound
effects.
Also tweaked the expected length of the Overture so that it syncs up
nicely with Act II: No. 10 Scène (Moderato) from the Seiji Ozawa
recording. It was apparently used as tempo reference for the Loom
soundtrack, though I don't know if this was the actual track used for
the Overture since No. 14 is almost identical.
The way the code is written, it should still work fine even if the track
is longer or shorter than expected. And, let's face it, most players
will probably skip the Overture once they've heard it a few times.
This track is a bit harder to isolate from the ballet recording, since
it's in the middle of a piece of music. But since all enhanced tracks
are optional, that's not really a problem.
For the Loom Overture to end, the music timer has to reach at least 278.
Keep the music timer updated for as long as there is a current CD sound,
even if the track itself has ended. If the track ends very early during
the Overture, skip ahead to the scene change. There will be several
seconds of silence, but this seems unlikely to ever happen to begin
with.
This is currently hard-coded for the Loom Overture, and counts the
number of SCUMM ticks that have passed since the song started. Perhaps
it would make more sence to query the CD position, but our CD audio
manager doesn't support that at the time of writing.
This allows EGA Loom and Mac Loom to use replacement audio tracks, e.g.
from the FM Towns or TurboGrafx-16 versions or, with a bit work, any
recording of the original ballet.
Currently the Ouverture doesn't work, since it relies on the music
timer being updated.
If the game is a talkie version, on which the verbs reference sounds, but
it is missing the sound file, and the user chose Voice Only, a warning
appears for every playback attempt.
Force subtitles on this case, to avoid these warnings.
Fixes trac 13151
AndywinXp
Donovan Watteau
athrxx
Le Philousophe
Torbjörn Andersson
Filippos Karapetis
Eugene Sandulenko
Orgad Shaneh
Paul Gilbert
sluicebox