The timers are replaced with "application" timers, which are checked in AudioMixer::tick()
The timerprocs for next and fadeout could potentially cause a game freeze.
This is because they could, under certain race conditions, come to a deadend
while trying to lock the mutexes for access to AudioMixer and Music methods.
The particular use case (non-deterministic) for this was loading a save game
while playing a game that had a music track playing (eg. at MA05, McCoy's balcony).
Here's a rough explanation of a possible lock situation (others could also be possible)
The "Main Thread" and "SDLTimer" threads (as reported from MSVC debug) could become hardlocked.
::Main Thread::
A. LoadGame() calls _music->stop(0u);
A1. Locks a Music::_mutex
A2. Calls vm->_audioMixer->stop()
A3. AudioMixer::stop() locks AudioMixer::_mutex [THIS DONE]
A4. calls the endCallback for the music which is Music::ended()
at Music::ended,
A41. lock a Music::_mutex (presumably this is ok, even though it's a second lock, because it's the same thread(?))
A42. call installTimerProc()
A421. which tries to lock DefaultTimerManager::_mutex from default-timer [THIS FREEZES] - conflict with B11
::SDLTimer::
B. calls timer_handler,
B1. calls DefaultTimerManager::handler()
B11. locks the DefaultTimerManager::_mutex from default-timer [THIS IS DONE]
B12. we try to service the callbacks from TimerProcs that are currently entered in the TimerSlots queue
B121. Such a slot is the AudioMixer BladeRunnerAudioMixerTimer, which has the AudioMixer::timerCallback()
B1211. which calls the at AudioMixer::tick().
tick() tries to lock the AudioMixer::_mutex [THIS FREEZES] conflict with A3
* AGS_Fire: Doesn't do anything, but allows games using plasma fire
effects to load and run.
All methods return 0
* AGS_AGI: Allows games who use AGI lowres effects to load and run.
Games using scaling mode 0 will be squashed on the screen, but others
should be playable without the screen effect.
I have also made the necessary changes to the PC-98 audio drivers which were written to work around the current situation, but now also need a different order in the destructors.
Previously we just spawned the usecode event, but to be faithful to the
original the intrinsic should do everything in Item::enterFastArea.
This also adds a workaround for a bug that was occasionally triggered when
returning to the rebel base in Crusader: No Remorse, and fixes an original game
bug in the process.
I.e. the dialog you get if you have saved games, where the game asks you
if you want to load or start a new game. Before, it would just make the
dialog unresponsive if you pressed Esc.
Fixes clearing all debug flags set on the command line
whenever the ScummVM save/load dialog is displayed from
within a game.
This reverts commit 1c4e15599f
ScummVM-Translations
antoniou79
Torbjörn Andersson
Annick Ecuyer
Filippos Karapetis
SupSuper
Lothar Serra Mari
athrxx
Walter Agazzi
Matthew Duggan
Eugene Sandulenko
alxpnv
Daniel Kamil Kozar
Paul Gilbert
sluicebox
djsrv