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.
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.