The allegro implementation returns -1 when called with a pixel
that lies outside the bitmap. Doing the same in the implementation
in ScummVM fixes a crash in some games.
The ManagedObjectPool uses const char * for pointers, and unfortunately
in ScummVM by default we have a hash function on const char * that
computes the hash on the string and not the address. This caused
various issues such as accessing freed memory. This changes matches
what the original interpreter does and fixes crash and scripts errors
in many games.
This matches what the original interpreter does and
This is mostly based on ZAK and MI2 disasm (and a bit LOOM). For MI1 and INDY4 I have at least checked with the FM-Towns UNZ emulator to ensure that they actually have the smooth scrolling.
The smooth scrolling is a bit tricky with regard to the timing. The scrolling tends to be a bit too slow for the engine, since it happens at a speed of 1 pixel per 60Hz tick, while the engine sometimes writes one or more new 8 pixel strips at the same time. So the scrolling often has to catch up to the engine. The original has a compensation mechanism which I tried to adapt. We'll see if it needs more fine tuning...
The Loom intro even glitches in the UNZ FM-Towns emulator due overflowing the scrolling surface (and causing a wraparound). But I made a fix for that.
Since we do have a bug report about the speed of the ZAK intro (and the new scrolling code does affect the timing) I have run the ZAK intro in ScummVM and in the FM-Towns UNZ emulator (with i80386DX, 16 MHz setting) side by side and they seem totally in sync. If I reduce the MHz setting in the emulator to 10 MHz on the emulator the intro will play slower, but still not play through the whole song. With 8 MHz I get close to finishing the song, but this seems to be almost to slow to run the game properly. So I'll leave that bug ticket open...
I have checked the behavior of original INDY4 and also DOTT (since it is a later SCUMM version). Both games do actually suppress the whole dialogue line when pressing '.', even when it is a multi part line (containing one or more '3' command codes). So we don't have a bug here. But this applies to speech enabled setting only. In text only mode the original allows to step through the dialogue line by line (and also through the message parts separated by the '3' command). I have fixed this from disasm so that it matches the original behavior. I've also confirmed for SAMNMAX from disasm (not extensively, just checked whether it has the voicemode == 2 check at the beginning of startTalkSound()).
Eugene Sandulenko
Henrik "Henke37" Andersson
Thierry Crozat
ScummVM-Translations
VAN-Gluon
athrxx
Ori Avtalion
Martin Gerhardy
Paul Gilbert
sluicebox
SupSuper
Matthew Jimenez
Matthew Duggan