This is the same in the original interpreter, but I assume
they just don't update the screen as much as we do.
The problem is that the new scene palette is
generated and set before the new scene is actually drawn. So there is a moment where the old scene is visible with the new palette...
The talkie version was silently killed while we completed the support for the regular Mac version.
Also cleanup all the LOK static resources a bit (remove garbage offsets).
This is only one of two steps. It slightly changes the detection so that the game always "remembers" whether it is Simplified or Traditional Chinese, even when the language is set to English, German or French.
(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()...
(The names will be displayed incorrectly in the GMM/launcher even if the GUI language is set to Korean. We don't have the required encoding (apparently ks_c_5601-1987 or similar).
Apparently in some builds the gScummVMVersion still contains the revision number (contrary to the comment in base/version.h, actually). I normally don't notice that, since it doesn't happen in my own builds. The long strings will break text fields that can't have strings of that length.
I'll now just generate my own version from gScummVMVersion, so I do get the desired (short) layout.
Apparently, as I have been told, there are (still) OS'es with non-compositing window managers which may cause glitches when drawing windows over the ScummVM window, unless the engine keeps updating the screen. So, now we do that, even if there isn't any actual on-screen activity. The whole thing is a bit more tricky than it would appear at first glance, since one misplaced/untimely screen update may cause palette glitches. I have implemented a timer which is reset whenever actual on-screen activity happens. That should work around any such glitches.
Maybe the rates for the timer have to be tweaked some more. I have also added an ifdef so this could be disabled or restricted to certain platforms if required.