Waxworks DOS has both digital and limited MIDI SFX. The game scripts use two
different opcodes for trigging digital and MIDI SFX; if a sound effect has both
a digital and a MIDI version, both opcodes are triggered. When digital SFX are
active, ScummVM would try to handle both the digital and the MIDI opcode by
playing a digital SFX. This would crash the game if the MIDI SFX ID was invalid
as a digital SFX ID. Strangely enough, this bug also seems to affect the Amiga
version. Apparently both opcodes are still in the scripts of this version, even
though it does not support MIDI at all AFAIK.
This commit fixes the issue by only playing the MIDI SFX if digital SFX are
turned off and ignoring them otherwise.
Simon1 and Simon2 fade the screen to black whenever leaving a room,
but this can be slow to render on some devices, and for some people
nowadays it can really make the pace of the game quite slow.
This adds support for the AdLib and MT-32 sound effects in Elvira 2 and
Waxworks. It adds an option to the UI to toggle between sampled and
synthesized SFX. It also adds the following enhancements:
- AdLib OPL3 mode for Elvira 2, Waxworks and Simon 1 floppy demo. This can be
selected using a new UI option.
- Mixed AdLib/MIDI mode for Elvira 2 and Waxworks.
- Implemented "monophonic chords", a feature of the original MIDI code which
would play only the highest note of a chord on AdLib. Most noticable in the
Waxworks music.
- Added UI option to select Simon 1 DOS music tempos.
- Rewrite of the AdLib and MT-32 drivers to remove duplication and make use of
features of the standard multisource drivers.
- Refactored MidiPlayer to standardize interface and remove code moved to the
drivers and parsers.
The first scene of the Simon The Sorcerer 2 intro uses 3 music tracks. The last
2 are missing from the MT-32 MIDI data set. The original interpreter just stops
playing music after the first track and does not restart until the next scene.
This commit fixes this problem by using the GM versions of these 2 tracks
instead and mapping the GM instruments to MT-32 ones.
MIDI music is now paused by pausing the parser(s) instead of relying on the
mixer streams to stop providing callbacks. This gives more consistent behavior
as external MIDI devices or softsynths now also pause playback.
Muting sound now sets the volume to 0 instead of pausing playback.
The whole restoreBlock() function looked strange. It said it took x, y,
w and h, but it seems pretty clear that what it expects is left, top,
right and bottom.
Except in one case, where the order of the parameters had been swapped.
The most visible result of all this was that The Feeble Files crashed
when you pressed the "Off" button in the Oracle interface.
I've changed the names of the parameters, and that one strange call, and
changed how the function calculates the dirty rect. Hopefully that
should be correct.
Just walking around the castle fixing bugs as I find them, e. g.:
- make decompression routine safer (this could write a couple of invalid byte in at least one case)
- also support compressed data header without actual data (required in the kitchen scene when killing the evil cook)
- fix some graphics/palette related glitches
- Add dual layer graphics display to display the Japanese characters in their proper (double) resolution on top of the graphics. The original actually uses text mode.
- Adapt mouse handling to dual layer code.
- For consistency I got rid of all direct calls to _system->lockScreen() and _system->unlockScreen(), even in the sub engines that aren't affected. I find it easier to debug and to maintain this way.
For each engine:
- Make a new folder detection
- Move detection-related files inside the folder
- Add a new module "enginename/detection"
- Add DETECT_OBJS here
- Adjust the normal engine module to remove detect_objs
- Adjust every file for the new changes.
Recent GCC versions complain if you memset() a class or struct that
contain non-POD data types. Get around that by either initializing
the object when created, or by adding a reset() method.
This attempts to restore the missing loyalty rating setting to the
4CD version of The Feeble Files. So far only for the English
version, since that's all I have, but it would not surprised me if
the other versions are similar.
This in fact slightly changes the priority order of added archives. Formerly,
all archives in SearchMan were preferred to the customly added ones in
ArchiveMan. All standard paths (i.e. path and extrapath) will be still be
searched before the custom ones (which are all priority 0 right now) but system
specific paths will be searched after (due to their priority being -1). Since
system specific paths shouldn't contain any game data files this should
hopefully be harmless.
This wasn't tested for games with CAB archives.
Now all of the Archive API is implemented to avoid possibly inconsistent
behavior when an ArchiveMan object is accessed via a class type higher in the
class hierachy.
Formerly the hasFile method was non-const, thus did not overwrite the virtual
hasFile method of SearchSet. Since all accesses to this function have been
done through a ArchiveMan typed variable, the missing overwrite should not
have caused any trouble.
It looks like this was forgotten in a6ec4f70da.
Playing with cabinet datafiles, this failed to find the "Charisma.smk"
file in the cabinets when in the Recreation (TV) room on Cygnus Alpha
and this caused an engine abort after the GUI dialog warning of the
"missing" video file. This was due to animation.cpp code using
Common::file::exists() instead of going via the ArchiveMan.
However,a hasFile() method implementation was also required to implement
fallback to decompressed (movie) files if the file requested is not in
the cabinet or the cabinet has been externally decompressed to files.
Thanks to fuzzie for the hasFile() patch.
Also, removed noisy warning which this correction triggers repeatedly in
installshield_cab.cpp hasFile(). This looks like leftover from
debugging, so not critical.
Now AgosEngine::_language is of type Common::Language instead of uint16. It is
currently only used with values of that enumeration, thus it should be safe to
use that type for it too.