(the Chinese version has a version string of its own hard
coded onto the bitmap. We have to move our scummvm
version string a bit to the right to avoid printing over the
other text.
The Chinese version doesn't have the credits, neither the player nor the required data files. So the enigne would crash when trying to load these. I have also checked with the original that it doesn't do anything else for the credits.
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.
Animations often run at full speed without any delays. Apparently the target hardware of that time (286/386, Amiga, Mac) would ensure sufficient slowdown. Unfortunately, comparing with DOSBox, ScummVM runs somewhat faster. I have tried to add extra delays depending on the amount of onscreen activity. I have finally gotten a result which is very similiar to DOSBox execution.
Basing this on the screen activity is not optimal. Ideally, it would be based on the orignal cpu activity. But we can hardly do that...
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.
