Playing around with the "talkspeed" values, the name of this setting may be counter-intuitive:
Higher values do not mean higher speed. Instead they lead to higher (longer) display time.
In other words, talkspeed zero is fast, 255 is slow.
Related discussion (from 2008, though): https://forums.scummvm.org/viewtopic.php?t=6496
Previously we used the Ultima 8 behavior of not terminating any obj id 0
processes on level change, but that occasionally left never ending "alarm has
been activated" background audio and similar problems.
This changes so that all but the "persistent" processes are terminated.
At the same time, also correctly clean up the snap egg and target lists when
changing maps - previously these were left sitting around.
"Animate^7" was an intermediate API function during 3.6.0 alpha
development, and apparently there are games which used it.
From upstream eb4c0aec426c1501c84e93851e9aa31eaf8e2f27
This is used by 3D games to limit the frames per seconds.
The default value was lost in commit b586571900 when sync'ing
ScummVM and ResidualVM code. This resulting in a default of 0,
which means no throtling.
This should fix bug #13631
(When skipping over a scene by left-clicking, sometimes parts of the ongoing animation would remain visible on screen, e. g. some of Herman's body parts in the cave at the beginning)
There's one call in unload_game_file(), which should be called after
all objects that may have been provided by plugins are disposed
(fonts, managed objects).
From upstream 462cabe7353fc75f3cf70222a97028066f12f030
Fixed getting stuck in a render attempt loop, because the window
events are not being processed.
From upstream 25329949f4d4a17ea8e6ad11fc7bd0ecccdfaca7
(in the first cave, when trying to cross the broken bridge and falling into the river, a "cut off" Herman's head could appear on screen beside the death dialog)
The animator code is a bit different here between versions. Our code was apparently based only on DOS CD (Talkie).
(The game restarts the last song which is stored in the savegame, but for many scenes the scene entry scripts will start the same song again right afterwards. This causes some audible "stuttering".
HOF and MR don't seem to require this fix. For these games the music restart is controlled via the last argument of enterNewScene(). If it is set to 1 then no song will be started. And that is what happens when calling from loadGameState()...
Was broken by 7a1ee192e2
Fixes bug #13477 AGS: Heroine's Quest intro shows portrait bug
This old commit was trying to fix a problem in old game(s), when
character was set to a loop with no frames. In such case the old
engine would seek for the first loop with frames, starting with 0.
The condition for doing so was made incorrect though: instead of
testing simply for a empty loop, it tested for frame number being
outside of the current loop's frame range.
This broke games where e.g. some walking view's loops were shorter
than the others.
A replacement is a condition that tests exactly for an empty loop
instead. The frame exceeding a loop's frame count is fixed later
along the way, so it's not a problem here.
From upstream ac73a555d737fb3f759cc7da9eeaf488a3bdcb2f
This fixes a possible infinite loop in VocStream. It depends on the stream size
matching the size specified in the VOC block headers, but if the size in the
headers is incorrect and larger than the stream size, it will keep trying to
read the stream. This is fixed by adding an end-of-stream check to the error
check.
Paweł Kołodziejski
Paul Gilbert
ScummVM-Translations
Thierry Crozat
antoniou79
Joachim Jautz
Lothar Serra Mari
Matthew Duggan
Torbjörn Andersson
athrxx
BeWorld
Thunderforge
Ben Castricum
Hubert Maier
Martin Gerhardy
Lothar Serra Mari
Coen Rampen
Filippos Karapetis