| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Also fixed enemy behavior along the way. No wonder it differed
from the original!
|
|
|
|
|
|
|
|
mine road"
There was a missing Sfx call.
|
|
|
|
This changes the warning to a debug and also updates the comment a bit.
Thanks to eriktorbjorn for checking Loom Mac in an emulator.
|
|
Skip music resources that don't have the "so" (song?) tag. It is
better than asserting, now that it turns out that they do exist.
|
|
RFC: Allow use of override and nullptr. Also allow C++11 compilation.
|
|
Added some comments to make it more readable. Switched usage of a temporary buffer and a double memcpy with a memmove.
Also fixed a potential out-of-bounds write, thanks to LordHoto.
|
|
|
|
Clang will produce plenty of warnings (most of them seem to be of
the "if the stars align the wrong way, this may happen" variety),
but I don't have the time or patience to look at all of them.
|
|
Unlike the EGA DOS version, it doesn't seem to be the scripts
that keep track of double-clicks. Instead, the engine sets a
variable to indicate them. Unlike the DOS version, we don't check
that the second click happens close enough on the screen to the
first one. We could, but it seemed needlessly complicated.
|
|
|
|
SCUMM: Add support for Macintosh music in Monkey Island 1 and Loom
|
|
After listening to the original music in a Mac emulator (which
unfortunately doesn't handle the music very well), I can only
conclude that note value 1 means the note should continue playing.
At first I thought maybe it was supposed to fade the current note,
or perhaps change its volume, but I can't hear any traces of
either. So I'm going to assume it just means "hold the current
note", though for the life of me I cannot think of any valid
reason for such a command. So it may be wrong, but it sounds
closer to the emulator than it did before.
|
|
Some notes in the main theme are very staccato, and this could
possibly explain why.
|
|
I completely forgot to delete the dummy iMUSE object after using it
to skip over the old music save information. Thanks to Lordhoto for
pointing this out.
|
|
SCUMM: Support OPL3 in Sam&Max
|
|
At least for me, hfsutils turns spaces into underscores so try both
"Monkey Island" and "Monkey_Island".
|
|
|
|
Initialise _channel[] even when the instruments aren't available.
Otherwise, ScummVM will crash in a number of places including,
but not limited to, when loading savegames.
|
|
|
|
After some discussion on #scummvm, the player now locks the sound
resource while the music is playing. This prevents the resource
manager from expiring the resource, which at best could cause
music to restart where it shouldn't.. At worst, I guess it could
have crashed, but I never saw that happen.
|
|
Properly treat rests as rests, not notes. Otherwise, it would try
to play a really low note which just came out as a "pop".
|
|
It shouldn't make any real difference, but it's probably more
formally correct.
|
|
In looped music, prevent the music channels from drifting out of
sync over time. This was noticeable after a few minutes in the
SCUMM Bar. We do this by extending the last note (which is just
zeroes, so we didn't even use to play it) so that it has the
exact number of samples needed to make all channels the exact
same length. (This is calculated when the music is loaded, so it
does not need any extra data in the save games, thankfully.)
As a result, the getNextNote() is now responsible for converting
the duration to number of samples (out of necessity) and for
converting the note to a pitch modifier (out of symmetry). I made
several false starts before I realized how much easier it would
be this way.
|
|
|
|
At least on my computer, when the note ended abruptly there would
be an annoying "pop" at the end. This was particularly noticeable
at the end of the distaff notes in Loom. To get around this, fade
out the last 100 samples. There's nothing magical about 100 in
particular, but it's a nice even number and it should be short
enough that it's never a noticeable part of the note, even at low
sample rates.
|
|
It was the remains of an experiment and no longer serves a purpose.
|
|
Mac Loom's drafts appear to be stored from variable 55 and upwards.
I'm working under the assumption that there's either only one
version of Loom for the Mac, or that they all behave the same. I
could be wrong about that.
|
|
It was never quite clear exactly what "drafts fix" did. It wasn't
guaranteed to work on all versions of Loom - or at all - and I
haven't heard any reports about the data structure getting
corrupted for years.
|
|
This keeps the music from breaking when loading a savegame that was
made with a different sample rate than the current one. It also
breaks all savegames made in the past eight hours, but I don't think
it's necessary to maintain savegame compatibility within a pull
request, as long as it still works with savegames made before it.
|
|
For old savegames, we now use a "dummy" iMUSE objet to skip the old
iMUSE save state. I had hoped to be able to do this without making
any changes to the iMUSE code itself, but I was unable to.
Also added note about how the save state for the new music will not
quite work if the mixer output rate changes. Personally, I'm not
too worried about that. It breaks, but it shouldn't break badly.
|
|
Note that while this removes _townsPlayer->saveLoadWithSerializer(s)
it really shouldn't break anything because _musicEngine also points
to the FM Towns player. Famous last words...
|
|
We no longer use iMuse for MI1 Mac so this never happens. The Mac
player can only play one song at a time, so it should be all right.
|
|
Apparently we cannot (portably) call virtual functions from the
constructor, so initialization has been moved to a separate function.
|
|
Try the Mac OS Roman form, the UTF-8 form and the filename without
any trademark glyph.
|
|
Excplicitly cast to int to avoid a warning that I don't get, but
which clone2727 does. At least, I hope it avoids the warning.
|
|
As clone2727 pointed out, the default case handles Loom. I guess it
was a special case before to *prevent* it from trying to play the
sound, and to keep some comments about the format.
|
|
The Monkey Island and Loom mac music is really quite similar. The
data layout is a bit different, but most of the code was easy to
separate into its own class. The Loom player doesn't do looped music
but I don't remember off-hand if it ever should.
|
|
It turns out that playing the Mac Loom music isn't particularly
different from playing the Monkey Island 1 music, except the data
layout is a bit different and there's no per-note volume.
|
|
Otherwise it may crash if you quit before any instruments have been
loaded. Oops.
|
|
This is based on the old Mac0-to-General MIDI conversion that we used
to do (and which this patch removes), as well as the code for playing
the Monkey Island 2 and Fate of Atlantis Macintosh music. I'm not sure
how accurate it is, particularly in tempo and volume, but at this
point it seems to work pretty well. Looping music is perhaps a bit
off, but it was before as well.
There is an annoying drawn out note in the music when you're following
the shopkeeper, but that appears to have been there in the original as
well.
|
|
This fixes a regression in V1/V2 games when no actor direction
is set (like the Shuttle Bus scene in Zak V2). The regression
was caused by commit de0b5f76749add219a6b667d5d2d69fb8a86d959.
Thanks to digitall for his bisecting work, which aided a lot in
finding the actual issue for this bug
|
|
|
|
This is an initial implementation and does not implement the differences
in voice allocation.
|
