The moveToFadeOutTrack() function was introduced many years ago to fix
"sound skipping a bit when a fade out track starts". Unfortunately,
while this may have worked flawlessly back then it causes crashes in
certain cases now.
The point of this is to avoid the crash for the upcoming release. A more
long-term solution should be in the works.
Kathy Rain and Whispers of a Machine use the ags_sprite_font plugin
and load the fonts in their game_start script. This script is called
when starting a new game, but not when loading a savegame on startup
(for good reasons). As a result when loading a savegame from the
launcher we were missing those fonts and it was using replacement
fonts that do not quite work properly.
This fixes bugs #12945 and #12964.
This fixes bug #12948 AGS: Segfault when picking up at police report.
For that bug the font is properly loaded by FreeType, but it is a
non-scalable Windows font whose size does not match the requested
size. The original AGS handles TTF font sizes differently to how we
do it in TTFFont (and also has some hacks on top of that), and it
was easier here to use WinFont that try to tweak TTFont to work
with this case.
(see https://bugs.scummvm.org/ticket/12499#comment:11)
In Actor::startWalkActor() we call adjustXYToBeInBox() twice, first with the dest coords, then again with the resulting coords from the first call. In the example from the bug ticket (clicking on Kenny the lemonade selling pirate) this will adjust the x position from 503 to 501 on the first pass and from 501 to 500 on the second pass.
The original SCUMM 5 and 6 (I checked MI2 and SAM) actually do it exactly like that, so it becomes kind of obvious where our code originates from.
However, for SCUMM 7 and 8 (I checked FT, DIG, COMI) the function has been simplified considerately. It makes the call to adjustXYToBeInBox() only once (and no call to checkXYInBoxBounds() either), so in our COMI example the x position will stay at 501.
The previous workaround value chosen to fix U8 bug #12913 really locked up
Crusader too long (>10 s), so there's no clean solution here that works for
both games it seems. Revert the threshold back for Crusader games only, and
keep the high threshold for U8. I hope the next time I touch this line is to
remove it because I work out the root cause of the problem :|
This fixes#12917.
The usecode "push byte" opcodes (0x0A and 0x5D) always push 16 bits on the
stack, but the ARG_UINT8 macro was only removing 1 byte. Most of the time this
went unnoticed because the UINT8 was the last argument in most cases (eg, a z
val), or unused.
This led to an inconsistency where sometimes z values were being popped with
ARG_UINT16 and sometimes ARG_UINT8. The original games do not support z values
beyond 254, so this should always be UINT8.
Additionaly, a while back "push byte" was fixed so it always sign extends, but
this could result in a case where we pop incorrect values. For example, a high
Z value could get sign-extended on push, and then popped back as a UINT16,
giving a z of 64000ish.
Fix by always moving the SP by 2 bytes, only use the first one.
Correcting this also fixes the strange color ordering I thought was needed for
I_jumpToAllGivenColor in Crusader: No Regret, where actually it should have
been popping the values as 16-bit instead of 8-bit.
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
Trying all engine plugins in alphabetical order is a time consuming
process, so start by trying the plugin which has the same name as the
engine id first, if it exists, as it will usually be the right one.
In the rare case that it would be the wrong one there is no problem;
the code will simply fall through to the old scanning and then record
the correct plugin in the engine_plugin_files domain where it will be
found the next time the plugin is needed.
Plugin filenames are all upper case on Dreamcast due to the ISO 9660
filesystem. It doesn't seem likely that making the check case
insensitive would cause any problems even on a file system that
is case sensitive.
