diff options
author | athrxx | 2018-12-10 00:39:10 +0100 |
---|---|---|
committer | Filippos Karapetis | 2019-04-02 20:45:35 +0300 |
commit | 037eec31446b64ec56b24e31d5be392390a694ba (patch) | |
tree | 96ff00ec6280e56975c342fa2e9efe98907f8078 /Makefile.common | |
parent | bc5ecb3b7c01e352c246f30789edd31d097f7c60 (diff) | |
download | scummvm-rg350-037eec31446b64ec56b24e31d5be392390a694ba.tar.gz scummvm-rg350-037eec31446b64ec56b24e31d5be392390a694ba.tar.bz2 scummvm-rg350-037eec31446b64ec56b24e31d5be392390a694ba.zip |
SCI: implement SCI0 midi driver track initialization
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.
Diffstat (limited to 'Makefile.common')
0 files changed, 0 insertions, 0 deletions