(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 :|
In March, b67c2d72d6c40fda2d67cfaf6a8aab9f44f7cd1e 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
Only the VDX player has a fast mode, and only The 7th Guest uses it. I
believe there's less use for it here, since the 11th Guest movies
already run at a decent frame rate.
From upstream 47001a398a1bc4ad022645ad21e1c891a3757167
Note: Since we don't implement alfont in full, the
referenced methods are stubbed in our alfont.cpp
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.
