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...
Works around script bugs in the original game that often accidentally
worked because of the time it took the original interpreter to load and
begin playing a sound.
Fixes bugs #10224, #10231, #10232, #10237, #10238
("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.
In SCI1 and later, kDoSoundFade does not test a sound's status.
Incoming fade properties are applied regardless of whether the
sound is playing and kDoSoundFade does not set the signal.
The code that's been doing this was added and updated in 2010
for ICEMAN and LSL3. Now it's only applied to SCI0 calls.
e41874c91df743468ec7
Verified in QFG2 1.000, JONES CD, and LB2 CD.
Fixes scenes in LB2 where multiple songs occasionally play at the
same time due to broken fade-outs. Hiding behind the tapestry
during a meeting is the one that occurred the most consistently.
Related to bug #6462
Fixes two discrepancies in redundant fade detection that were discovered
while investigating LONGBOW bug #13674:
- MusicEntry::fadeTo was altered even when the fade was ignored
- Redundant fades are allowed in SSCI when the stopOnFade flag is passed
The existing workaround prevented a crash but it performed volume tests
on an object's offset and abruptly ended the bandit music instead of
fading it out as in the original.
The broken kDoSoundFade call is redundant because a second script calls
kDoSoundFade correctly at the same time. Now the broken call is ignored
and the music fades out normally.
Bug #5078
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 really a necessary fix, so recommended for merging before the release.
The negative global pause counter (that I really added only for the GMM/autosave situation) may not be used from within kDoSoundPause. It causes issues, the counter will go out of the expected range (also, the "Music also seems to randomly disappear when saving / restoring games" mentioned in ticket no. 13496 might be related to this).
I didn't see this, since we were focussed on SCI0. But it can be easily tested with e. g. LSL1 VGA. Just save right at the start and restore the game, it will call kDoSoundPause and trigger the issue...
Fixes bug #13500 where LSL6HIRES doesn't play the audio for the death
message after the security guard launches a missile.
Thanks to @RayKoopa for reporting this and other discrepancies
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...
In March, b67c2d72d6 moved some MIDI
initialization from the main thread to the MIDI thread. This caused
MidiPlayer_Midi::sysEx() to run on the MIDI thread for the first time.
This is a problem because it calls SciEngine:sleep(), which polls
events, and that causes MacOS to throw an exception for calling
SDL_PollEvent() on a non-main thread.
While investigating, it also turns out that MidiPlayer_Midi::sysEx()
and MidiPlayer_Fb01::sysEx() were calling OSystem::updateScreen(),
and that also shouldn't be happening on a non-main thread.
Now SciEngine::sleep() is only called on the main thread, and
OSystem::delayMillis() is called on the MIDI timer thread.
Continuing to call sleep() on the main thread keeps the UI responsive
when loading patches, which can take several seconds.
The OSystem::updateScreen() calls had no effect and have been removed.
Fixes bug #12947
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
- Windows-only samples now respect "Prefer digital sound effects" config
- Windows-only samples now only applied when a regular digital sample
doesn't exist. This is SSCI behavior and mildly affects two sound
effects in the monolith burger mini-game. Confirmed in disassembly.
- Windows-only samples now play in Windows mode and DOS samples and
MIDIs play in DOS mode.
- Default audio experience now matches the selected platform.
This multi-lingual version handles audio in a unique manner.
English audio is only on the CD audio track while the other
four languages are only in resource files. This is transparent
to the scripts that play audio; they're the same in all versions.
This required a custom interpreter that detects the language and
handles English differently. It even has a custom error message:
"You will not be able to play the 'ENGLISH' version."
Fixes bug #12431
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.
Now that we match SSCI behavior when it comes to interrupting samples
when new samples play, we need to implement kDoAudio(13) so that the CD
version of Freddy Pharkas can detect these interruptions. Otherwise,
the game will softlock if the points sound effect or narration is
interrupted.
athrxx
Cameron Cawley
Hubert Maier
sluicebox
Donovan Watteau
D G Turner
Eugene Sandulenko
Orgad Shaneh
Filippos Karapetis
Paul Gilbert
SupSuper