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.
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.
These should really be refactored in the future to use a memory buffer. Moderns systems have enough memory that it shouldn't be a problem to store a copy of the currently loaded background.
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...
This is changed from "int" to "number" for uniformity with the rest
of the game options (plus, "number" is better understood by
non-programmers, whereas "int" is more cryptic)
This is possible, since the game is freeware now. It is very
helpful when playing the game in order to avoid referring to the
manual. The extra help text is shown when the player uses the
'help' command inside the game terminal.
Also, the list of games where copy protection is skipped has been
reordered alphabetically in the README
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.
This is now standard behaviour, and the current situation creates
problems for distribution packagers trying to generate debug packages.
A standard "install-strip" target has been added to enable the previous
behaviour if needed.