When skipping the intro via 'Esc' and 'Skip' the script
sets up a pause which it won't release later. This brings
our pause counters out of sync and triggers an assert.
This fix should work around this...
("hanging MIDI notes")
The original interpreter resets the channels more often than we do
in the remap function. The assumption apparently was that the
loop at the very end of the function would catch everything. But
it does not catch the dontRemap channels if they are not within
the _driverFirstChannel/_driverLastChannel range.
If more bugs like this come up it might be necessary to add even
more resets, but I am very reluctant about unnecessary changes
to the remap function. And this code has been around for a long
time without any other bug reports of this sort. So I think we have
reason to be optimistic about it.
This cleans up some things I noticed when I implemented the mute flag handling. It removes the hack that manually forces flag 2 on all channels with number 9, regardless of the device.
I presume the hack was done for the earliest SCI 1 games, due to improper handling of flag 1.
…once)
I am not sure if this bug ticket is about just one or about several bugs. This is at least something I could reproduce. The reason is that there can be channels that should start up muted. We didn't support that. I also fixed a couple of other things about the mute state that I noticed.
Make use of the mixer's mutex instead of creating a new one. Otherwise there can still be lock-ups when the main thread and the mixer thread lock each other up in different mutexes (causing a deadlock/freeze). I just noticed this with KQ5 FM-Towns.
We had the same issue in AGOS, it was fixed by allowing to access the mixer's mutex. We can use the same thing here...
This is similar to what we recently fixed for the saving. It does concern only the loading from the SCI menu and from the SCI death dialog (that's how it got my attention).
I have written a long comment in SciMusic::resetGlobalPauseCounter() which explains it.
I have decided to make this very obvious (you could say: more ugly), so it won't cause confusion in the future. Of course, it could be just hidden somewhere deep in SciMusic::saveLoadWithSerializer() and noone would ever notice. But the "ugly" way seemed the safer thing to do...
Fixes an out of bounds write that occurs when the config setting
"prefer_digitalsfx" is false and a game plays a sound resource
that contains a digital channel, such as SQ1.
The MIDI branch of SciMusic:soundInitSnd() wasn't skipping the
digital channel, which has the number 0xFE, and so it used that
to index the 16 element channel array.
This problem didn't become apparent until recently when
"prefer_digitalsfx" was fixed to apply to these sounds:
648d669c2d
The last 2 commits might not be fully compliant with the ScummVM GMM code and our handling of global sound pausing/resuming. This commit makes sure that only sounds will resume that were actually playing.
This mainly concerns restoring sounds after loading savefiles, but it should make the whole relationship between playing and paused sounds more accurate.
The test case which I was told about was KQ4, room 21, picking up the golden ball under the bridge, saving during playback of the pickup sound and then loading that savegame. It would result in hanging note due toe the sound being triggered multiple times by reconstructPlaylist() and updateSci0Cues(). Now, the sound should only start once.
I've changed the code to be more in line with disasm and tested some situations that sluicebox told me about or that I found in the comments (ICEMAN room 14, LSL3 start scene). I got rid of isQueued, since the original doesn't have that, it has caused some confusion and doesn't even get saved with the savegames.
I cleaned up updateSci0Cues(), so that it (together with processUpdateCues()) does a bit more what the original Midi timer proc does there. An exception is the sound fade out code in processUpdateCues(). It seems that we need that, as we don't have the fading code in the drivers like the original.
The original SCI0 code is actually much simpler than our code. It relies on a correctly sorted playlist (based on priority), but my impression is that we got that right, even if we do it slightly differently. I added a sortPlayList() to the sound init, since the original inserts the node at the right position, too.
When _mainThreadCalled is set the function call should be enqueued just like the Midi messages that get sent before the start of a new track, so that everything happens in the right order.
Up until last commit, everything was working fine but the amount of files changed was too large. This commit tries to reduce the changes.
- Add a fake constructor to Keymap, text-to-speech, setDescription (save-state)
- Redirecting functions for PopUpWidget::appendEntry, ButtonWidget::setLabel, GUIErrorMessage
- Use the above functions and constructors to reduce changes in Engines
- Fix warnings being in unicode. Only output english text in - Warnings, Errors, etc.
- Mark some strings as "translation" strings. (Not yet added to POTFILES)
- Remove some CP related things from po/modules.mk
- Previously used some Common::convertToU32 where it was not necessary, replace this with u32constructor
After the initial changes just to scummvm/gui for u32, this commit includes the whole project
- Widget creations now always have u32 descriptions, labels, or tooltips
- Message dialogs make use of default arguments instead of providing the same argument explicitly
- encode String::format properly before passing on as argument where necessary
- Modify hugo utils (yesNoBox and notify box) to use u32
- Also provide fake constructors for the above which redirect to the u32 constructor
- Convert all keymap descriptions to u32 across all engines
- showConfirmationDialog in mohawk now uses u32
- showScummVMDialog also uses u32
- Scumm engine has dialogs now which use u32
- General fixes and wrapping convertToU32String for setLabels and related functions
- Add a fake constructor to MesssageDialog which redirects to the u32 constructor
SCI01/SCI1 games have sound effects in SND files, which contain both
digital sounds and their alternative MIDI counterparts. Allow the user
to listen to the alternative MIDI counterparts by unchecking the
"Prefer digital sound effects" checkbox, like with other SCI versions.
Fixes bug #11587
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...
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).
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).
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).
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.
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.
Upon investigation of Sound code across SCI32 games, it was
determined that there are actually (at least) 3 different
revisions, not just a single SCI2.1 version. This patch only
changes the parts of Sound code that are relevant to the correct
use of Audio32.
Fixes Trac#9736, Trac#9756, Trac#9767, Trac#9791.
GK1 handles MIDI volume by changing the volumes of individual
sound objects, rather than by using the MIDI master volume. As a
result, the master volume needs to default to the maximum output
level in order for GK1 to play music at the correct volume.
This change does not affect earlier games, since SCI16 managed
MIDI volume via the master volume, and for these games the master
volume from ScummVM is synced at startup.
athrxx
D G Turner
Eugene Sandulenko
Orgad Shaneh
Filippos Karapetis
sluicebox
aryanrawlani28
Walter van Niftrik
Colin Snover
Ruud Klaver