There are many situations that GM sounds worse than MT, even for games
that were written for GM.
I think this is related to this.
And, there is a note in midi.cpp:
// NOTE: SSCI uses channels 1 through 8 for General MIDI as well, in the drivers I checked
Also, issue #6686 reports that using the "higher" channels causes
problem on a real SC-55.
This change solves at least: #6686, #9735 and #10297
This adds support for the Roland GS drumkits used by SQ5 and QfG3.
The original Sierra GM driver does not pass the drumkit select MIDI
messages to the GM device, but they do exist in the MIDI data.
Another issue is that the drumkit numbers used are incorrect. This
does work on the original Roland SC-55 devices because they correct
the drumkit numbers. Later devices do not do this. Code has been
added to correct these wrong drumkit numbers.
This adds specific support for SCI0_EARLY targets.
Based on and tested with Christmas Cards 1988.
I've not added the volume reset (neither for SCI0_EARLY nor SCI0_LATE), since the ScummVM driver seems to handle volume differently on purpose (probably based on SCI1?).
I put this in an separate commit to make it easier to review/revert. I've tried to make this as minimum invasive as possible. That's why I put this in place of the former call to onNewSound().
SCI_0_LATE sound drivers (probably also SCI_0_EARLY, but I don't know that) do some midi track initialization, mostly resetting certain values and assigning voices (hardware channels) to midi parts. The information for this comes from the track header.
The SCI0 version of the PC-98 sound driver relies on this code. The driver checks the channel flags with two different masks and assigns different sound channel types accordingly. This can't be done with the 0x4B event. Using the 0x4B event is sort of counter intuitive anyway, since only some of the SCI0 drivers even support that event.
It seems that the only driver making use of onNewSound() was MT-32. I've adapted the driver to my changes, although I am quite sure that the sound will be unaffected. The only thing that the MT-32 driver does with the header information is checking whether a midi part should play or not and assign exactly one timbre (with exactly the same number) to that part if required.
Set the default reverb configuration present in either the MT-32
patch data or MT32.DRV of SCI0 games before playing each sound, as
a previously played sound may have changed it.
Also, do not perform a general reverb init, since the start of a
sound will do that now.
Closes gh-1023.
Real MIDI devices, and MT-32 in particular, need delays between
SysEx messages to ensure sufficient time to receive and process
the incoming data buffer. Sending too much data too quickly to
these devices can cause them to crash with a buffer overflow.
The MT-32 emulator, on the other hand, has no problem receiving
SysEx data instantly, so skipping the delays means that games that
send lots of data to the MT-32 will start up much faster.
- Detection works via signatures (couldn't find a better way)
- new kString subcalls were introduced SCI2.1 LATE
- kString now has signatures and is split via subcall table
- kString fix, so that KQ7 doesn't crash, when starting a chapter
- Sci2StringFunctionType removed, because no longer needed
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 renaming allows us to better distinguish that this version is for games
that only had an EGA version, and avoid confusion with newer SCI1 game releases
with EGA graphics (e.g. KQ5 EGA). The only game with this SCI version is QFG2,
a SCI1 EGA game with a parser. Also, added some games for each SCI version.