| Age | Commit message (Collapse) | Author |
|---|
|
- The mutex was added to avoid the triggering of the assert in backends/midi/windows.cpp, line 95. Meanwhile, this issue has been addressed differently.
- SCI does not per se require a mutex for the sound drivers. The engine is mostly thread-safe by avoiding driver calls through the main thread.
|
|
Sound:vol is updated when updating cues starting in SCI_VERSION_1_MIDDLE.
Fixes bug #10244. SQ4 localized floppy versions depend on this when getting
in the orange ship, they fade music and wait for the volume to reach zero.
Confirmed against asm that this is not in SQ4 floppy (early) but is in
LSL1VGA (middle) and SQ4 localized floppies and SQ4CD (late).
|
|
(add another mutex lock)
|
|
|
|
|
|
- Backport some code of waltervn's fork at his recommendation (taken from 97604200 and 4c3bfee5). That code has caught some bitrot and I were too lazy to manually resolve the merge conflicts. All changes have been re-checked with disasm.
- Add initTrack() implementation for SCI0 EARLY/LATE
- Minor cleanup
- Please note that this commit does not fix any shortcomings of the SCI sound engine
|
|
|
|
After implementing such a dialog into the fb01 driver it did make sense to me to also have this as a feature for all other aftermarket drivers/patches.
So now the sound drivers can report missing files after the failed open() call which will then be displayed in a dialog. Which will at least be more helpful than our usual error messages...
|
|
Fix SCI0 (LATE/EARLY) variants of the driver which were broken (didn't play at all). This might be of my own doing, since I introduced the initTrack() method into the driver class and the fb01 driver didn't have one so far.
SCI1 didn't seem to require much fixing. I modified some things according to my findings in the driver disasms. QFG2 and JONES seem to be fine. I am not too happy with KQ5. It has volume issues, but they might be present in the original, too.
I also added an isOpen() check and a mutex to avoid threading issues. When aborting SCI (either quitting ScummVM or returning ot the launcher) while using the fb01 driver I frequently (more often than not) got the assert from backends/midi/windows.cpp, line 95. This fixes that.
I've done plenty of checks and experiments with the sound bank initialization. But I found no bugs or possible improvements there. Hard to tell whether the sound is right. That device seems to have a mind of its own...
|
|
|
|
Pitchwheel and channel volume settings need to be updated when the channels get reassigned.
This bug caused faulty music at least in KQ5 when walking from the dwarves scene into the harp playing tree scene.
|
|
(This triggered an assert in PQ2 at the airport. I've added a warning instead, since the original driver has no handling for that sort of thing. Invalid programs will simply point into invalid memory blocks)
|
|
I haven't found an elegant and non-intrusive way to squeeze SCI0 support into LordHoto's existing code. The drivers are too different. So I made some rearrangements. The basic mechanisms of LordHoto's SCI1 code should remain the same as before, though. I only introduced some more classes, moved some code into these classes and renamed some things (mainly for myself, so as not to get confused).
I fixed two voice mapping bugs in the existing driver code. The first bug in bindVocies() effectively hindered the driver from playing anything at all when the CMS_DISABLE_VOICE_MAPPING #define wasn't set (_voice[i].channel == 0xFF instead of _voice[i].channel != 0xFF). The second bug in unbindVoices() was not a complete show stopper, but the function simply did not "unbind the voice". The line which does the actual removal of the channel assignment was missing.
The SCI0 driver portions have been tested with: PQ2, KQ4, LSL3, QFG1, ICE and COC.
SCI_0_EARLY versions apparently don't support the CMS. At least I haven't seen a driver file so far. And there seems to be no no instrument patch resource. Although the latter issue needn't necessarily be one, since the patch data array in the driver is actually preset with data (which gets overwritten as soon as a patch file is loaded). Maybe this would work for SCI_0_EARLY. However, I haven't tested this, since I really would have have a look at a driver file first if one actually exists. For now, I have limited the driver to SCI_0_LATE.
SCI1 has been tested with KQ5 and LSL5 (not extensively, just to see whether anything got broken and whether my voice mapping fixes work).
|
|
|
|
Fix up SCI0_LATE variant of the driver so that it actually plays anything (and even correctly). SCI1 hasn't seen any testing from me so far. I don't know whether that version works. Same for SCI0_EARLY...
|
|
I haven't found an elegant and non-intrusive way to squeeze SCI0 support into LordHoto's existing code. The drivers are too different. So I made some rearrangements. The basic mechanisms of LordHoto's SCI1 code should remain the same as before, though. I only introduced some more classes, moved some code into these classes and renamed some things (mainly for myself, so as not to get confused).
I fixed two voice mapping bugs in the existing driver code. The first bug in bindVocies() effectively hindered the driver from playing anything at all when the CMS_DISABLE_VOICE_MAPPING #define wasn't set (_voice[i].channel == 0xFF instead of _voice[i].channel != 0xFF). The second bug in unbindVoices() was not a complete show stopper, but the function simply did not "unbind the voice". The line which does the actual removal of the channel assignment was missing.
The SCI0 driver portions have been tested with: PQ2, KQ4, LSL3, QFG1, ICE and COC.
SCI_0_EARLY versions apparently don't support the CMS. At least I haven't seen a driver file so far. And there seems to be no no instrument patch resource. Although the latter issue needn't necessarily be one, since the patch data array in the driver is actually preset with data (which gets overwritten as soon as a patch file is loaded). Maybe this would work for SCI_0_EARLY. However, I haven't tested this, since I really would have have a look at a driver file first if one actually exists. For now, I have limited the driver to SCI_0_LATE.
SCI1 has been tested with KQ5 and LSL5 (not extensively, just to see whether anything got broken and whether my voice mapping fixes work).
|
|
(somewhat difficult to make out any difference, but it does affect the envelope processing)
|
|
|
|
|
|
I haven't found an elegant and non-intrusive way to squeeze SCI0 support into LordHoto's existing code. The drivers are too different. So I made some rearrangements. The basic mechanisms of LordHoto's SCI1 code should remain the same as before, though. I only introduced some more classes, moved some code into these classes and renamed some things (mainly for myself, so as not to get confused).
I fixed two voice mapping bugs in the existing driver code. The first bug in bindVocies() effectively hindered the driver from playing anything at all when the CMS_DISABLE_VOICE_MAPPING #define wasn't set (_voice[i].channel == 0xFF instead of _voice[i].channel != 0xFF). The second bug in unbindVoices() was not a complete show stopper, but the function simply did not "unbind the voice". The line which does the actual removal of the channel assignment was missing.
The SCI0 driver portions have been tested with: PQ2, KQ4, LSL3, QFG1, ICE and COC.
SCI_0_EARLY versions apparently don't support the CMS. At least I haven't seen a driver file so far. And there seems to be no no instrument patch resource. Although the latter issue needn't necessarily be one, since the patch data array in the driver is actually preset with data (which gets overwritten as soon as a patch file is loaded). Maybe this would work for SCI_0_EARLY. However, I haven't tested this, since I really would have have a look at a driver file first if one actually exists. For now, I have limited the driver to SCI_0_LATE.
SCI1 has been tested with KQ5 and LSL5 (not extensively, just to see whether anything got broken and whether my voice mapping fixes work).
|
|
(somewhat difficult to make out any difference, but it does affect the envelope processing)
|
|
FPFP calls kDoSound SendMidi on non-midi sounds. Fixes bug #10952
|
|
|
|
|
|
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?).
|
|
The square sound channels will be out of spec when playing on the lowest octave. The result is a rather ugly noise. This bug makes a rather subtle appearance if the channel remapping is accurate, but it becomes quite obvious in the SQ4 intro with the current implementation. This commit turns off the channel when trying to play out of spec.
|
|
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.
|
|
This fixes two evalutation issues specific to the MSVC x64 release build (other builds worked fine).
This also fixes an analysis warning regarding my use of the span code.
|
|
- this supports PQ2 and QFG1
- also add several other fixes
|
|
(supports SCI1 for now)
|
|
Tell MidiDriver_AmigaMac the game's platform instead of it
attempting to infer this by which patch resources exist.
Fixes bug #10925 where SQ3 German Amiga is treated as Mac because
it happens to contain a patch 7 resource.
|
|
|
|
- workaround to fix music playback in Mixed Up Mothergoose
- remove a useless declaration
|
|
|
|
Fixes bug #10412
|
|
|
|
|
|
By default, frac_t is interpreted as signed. The resulting range isn't
large enough to store offsets, so we interpret it as unsigned here
instead. Fixes a crash in QfG1/Mac where instrument->loop_size is 49457.
|
|
Due to the need to calculate the audio duration with millisecond
precision from the file size, it is possible to overflow a 32-bit
integer in games with long background audio loops, like RAMA,
during the calculation of the duration.
It is also not necessary to give some framerate here, so eliminate
the unnecessary explicit Timestamp construction with the second
argument.
|
|
|
|
This was a regression introduced by
d556dcc57bf50a03d81ab7a1ef59a9e5758465bf.
|
|
* Rewrap comments to 80 columns
* Remove resolved TODOs
* Use containers and smart pointers where appropriate
|
|
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.
|
|
If the user has "Prefer digital sound effects" disabled for a SCI0
game, do not play the digital sample version of a sound resource, if
such data is present. When the resource has only digital sample data
and no MIDI information, play the sample instead.
Closes gh-1022.
|
|
Trying to find differences in Lighthouse's audio sample playback,
I discovered that SCI3 had its own variant of handling volumes and
sending this volume information back to game scripts. It is not
known if this fixes any sound bug.
|
|
Used by RAMA, in various places, starting with the refrigerator
at base camp after the cable car at the beginning of the game.
|
|
Which were originally only played, when using the Windows interpreter.
Afaik the DOS interpreter was incapable of playing more than 1
sample at a time, which was probably the reason why Sierra only
added these for the Windows interpreter.
For example a sample is now played, when points are awarded.
Those samples are currently used all the time and will also
enhance the game, when platform DOS is chosen.
In case someone wishes to opt-out of this, we could add a game
specific option.
We do something like this for Space Quest 3 already,
that's why I don't see a reason to add a game option right now.
|
|
|
|
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.
|
|
|
