This workaround disables PCM playback.
The PCMPlayers _chunk is NULL but _state is S_MID.
As a result getNextChunk always return 1, leading to readBuffer in
the playback thread never unlocking _mutex.
Until now, the TinselV* defines were used for discerning between
engine versions. The define TinselV2 was true for both v2 and v3.
Sticking to the old scheme would lead to confusion when more
special paths for v3 are implemented.
This version is using the same graphics format as the PSX version, with
differences in resource endianess, but features digital music with a
different track structure and has a different sound sample format
Pending issues:
- Font rendering is wrong - this is evident in the text and menus in
the game title screen
- Cursor sprite and trails are wrong - can be seen in the menu of the
game title screen
- Digital music is not supported yet - seems that a different track
structure is used
- The sound sample format is different than the PC version - looks to
be raw, but isn't
- The game crashes at the first room after watching Rincewind's waking
up cutscene
- added support for MIDPAK.AD timbre files on top
FAT.OPL. FAT.OPL gets copied by installer into MIDPAK.AD for this version
- changed order of timbre file checking
- adjusted and improved comments about discworld 1 versions
eriktorbjorn owns a version of DW1, that only has FAT.OPL and no
SAMPLE.AD/SAMPLE.OPL. We check if SAMPLE.AD/.OPL are available,
if not we try our luck with FAT.OPL
This is the second attempt. All the BE resources of DW1 Mac are
handled correctly now. Added READ_16, READ_32, FROM_16, FROM_32 and
TO_32 to handle all of the different cases where endianess is
already handled. Note that the game scripts are LE, so these
haven't been changed
Refer to bug #3110936
This is still work in progress, but it doesn't affect the rest
of the LE versions of DW1. Both the Mac demo and the full
version still crash. The music in the Mac version is skipped for
now, as it isn't MIDI
Previously, SetMidiVolume() would stop the currently playing track when
the MIDI volume was set to 0. Now, the music track always plays, even
when the volume is set to 0. This fixes bug #3541533 - "DW: Silencing
music volume stops music" and resolves two FIXME comments
Removed the superfluous MIDI offset storing code. Now, the MIDI buffer is
re-read when the music loops. This removes a static variable and also
fixes another bug in the SEQ decoder.
This also should fix some regressions from the previous
commits, related to MidiParser's either being leaked,
or being deleted and then used again (i.e., crashing).
I tested as many games as I had available, but further
testing of all affected engines is called for anyway.
The regression affected AGOS and maybe some others; specifically,
the real MidiDriver would have been deleted twice -- I previously
missed that the Engine instances takes care of freeing the real
MidiDriver, not the MidiPlayer wrapping it.
This commit should clarify the ownership of the real MidiDriver for
most pseudo MidiDrivers.
Many engines follow the advice in audio/midiparser.h and create a
"pseudo-MidiDriver" subclass. But MidiParser really only needs a tiny
subset of the MidiDriver capabilities, namely those found in
MidiDriver_BASE. So we try to subclass from that whenever possible; this
allows us to remove many stub methods, and enables further future
simplifications.
This in turn enables modifying MidiDriver_MPU401::close() to allow
it to be called on a midi driver that has not yet been opened.
The specific issue that triggered me to make these changes was a
crash-upon-quit in HUGO, caused by it instantiating a midi driver,
then encountering an error (missing hugo.dat) *before* having
opened the new midi driver; the general cleanup code then tries
to close the (not yet opened) midi driver -> kaboom
Also fixed some engines which were leaking MidiDriver instances.
