This is a follow-up commit to 8cbcde0c (bug
https://bugs.scummvm.org/ticket/12666). While that commit improved the situation, in particular the behavior described in the bug ticket, it still wasn't anything like pixel-perfect.
The agents would walk in a weird half circle due to being showered with walkActorToActor calls from the script.
I have now implemented the original walk code and also compared the first part of the INDY3 scene described in the ticket frame by frame with the DOSBox debugger to check whether it is truly pixel-perfect.
The particular scene with Indy and Donovan's men had all sorts of pathfinding issues compared to DOSBox:
- Indy's initial facing was downwards instead of to the right when walking from the window to the "meeting point" and the path he walked wasn't exactly correct.
- One of Donovan's men was facing down instead of left.
- Indy would take several weird up and down walks at the walk box transition from box 1 to box 3
- Indy would walk over the grass instead of on the road.
All fixes are from disasm. Some code I have removed (or rather commented out) seems to have been meant as a fix for bug no. 1778. So maybe that one has to be fixed again (correctly), but I don't know that yet.
The scene is not 100% fixed yet. Donovan's men walk a bit too much upwards in the beginning. But I can do that separately...
It will really be necessary to do some testing (and possibly more fixing) in the catacombs, in castle brunwald and in the zeppelin maze.
This is only supposed to apply to SCUMM3. It is a bit difficult to recognize this from SCUMM1/2 disasm, since things happen in a different order there. But it actually causes glitches in SCUMM1/2 (actors are slowed down sometimes) and it isn't required for bugs like no. 12278 (which has been fixed for SCUMM1/2 by one of my other recent commits).
4594: "Zak keeps walk animation without moving"
4601: "SCUMM: Zak McKracken (FM-Towns) - shopkeeper keeps walking"
Bug 4594 also happens with the original ZAK FM-TOWNS interpreter (unlike SCUMM1/2). I have added a workaround similiar to PR #2991.
Bug 4601 does not happen with the original, although it seems to have the exaxct same cause and is also fixed by this workaround. So I have stopped exploring this one for now.
I have limited the workaround to ZAK, since the bug reports are all from that game. To me, it looks like an oversight when converting the original SCUMM1/2 scripts to SCUMM3.
This is only the fix for SCUMM1/2. It fixes at least the bug described in the ticket (clicking on the shop manager after buying a lotto ticket). Unlike later versions V1/2 adds and removes the MF_TURN flag on the actor without touching the other bits. I have verified this from disasm and dosbox debugging.
While testing fixes for bug no. 12278 I also noticed that the actor facing when walking diagonally did not match the original behavior when I had the ZAK intros running in ScummVM and UNZ (for Zak-Towns) and ScummVM and DosBox (for Zak-DOS-V1 and V2).
This is about the decision whether a character that walks diagonally should face up/down or left/right. I implemented the original method to determine the facing.
Our current interpolation does not always turn characters in the same direction as the original, e. g. when walking straight up or down the original will always turn the character counter-clockwise. I implemented the interpolation table used by the original interpreters for more faithful display. Verified visually for v1-v3, and from disasm for v3 and v1.
(Loom (VGA) - Graphical glitches where some text appears over previous line and the wood musical note disappear)
The glitch is caused by a workaround in ScummEngine::actorTalk(). Removing it will make the original bug (speech animations for empty text strings) reappear. I have located the code which prevents that in LOOM DOS EGA disasm and added that. The FM-Towns versions don't have such code, but I do not get that weird speech animations either. So it seems to be fixed in a different manner there...
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()).
Recent GCC versions complain if you memset() a class or struct that
contain non-POD data types. Get around that by either initializing
the object when created, or by adding a reset() method.
This happens when clicking on the triangular button in room 27 in
The Dig.
There are probably several other places where this overflow
happens, since there are several different `int args[16]` in
the code (and many more `int args[` of various sizes, not all of
which are at least NUM_SCRIPT_LOCAL).
Since case 64 was added for "MM C64 Costume Animation", and
considering the way it's written to only affect game version 0,
it is clearly an intentional fall through.
athrxx
Paul Gilbert
Torbjörn Andersson
sluicebox
Orgad Shaneh
mataniko
D G Turner
Robert Crossfield
Colin Snover
Eugene Sandulenko
Kirben
Alexandre Detiste