[Scummvm-devel] Fixing walking in ZAK and MM (volunteers?)

[Max Horn]

Hi there,

I just was looking at some old bug reports which reminded me of the  
following problem. Maybe somebody is interested in working on a  
proper solution.

Essentially, actor walking in ZAK and MM is bugged in various places.  
The reason (or at least part of the reason) is that those games were  
not pixel based, but rather used block coordinates, where a block is  
8x2 pixels big.

Now, back when I implemented support for that in ScummVM, I used the  
quick & dirty route -- I simply upscaled all coordinates to be pixel  
based. That is the easiest way to do it, and it has the "advantage"  
that you get pixel-perfect resolution for free. This "advantage",  
though, is really a disadvantage (and I am not talking about the  
spiritual goal of achieving "perfect emulation" here). Those games  
simply were not designed for pixel-based actor movement, and this  
shows in various places.

I'll give a simple example as to what is going wrong at the end of my  
email.

The thing is, I believe now that it might be impossible to properly  
fix all the walkbox issues in V0-V2 games unless we properly  
implement actor walking in terms of the 8x2 blocks, abandoning the  
pixel perfect actor positioning in these games. In particular, I  
think the following bugs may (at least partially) be caused by our  
current "hackish" code:

#751662   ZAK: Zak appears in wrong position (cosmetical)
#771483   ZAK: Pushing Sarcophagous feet on Mars
#959001   ZAK: Can't give Annie the lighter in Katmandu
#1329465  ZAKV1 Stewardess stuck if called after egg-explosion
#1329498  ZAKV1 Possible to walk through objects
#1508005  ZAK V2:minor animation and walkpath error
#1538260  MANIAC: Characters walk through air when using stairs

So while the task is not an easy one (in particular, care must be  
taken to not break all the other games... not to mention savegame  
compatibility, though that could be considered last), the potential  
gain is noticeable.

Bye,
Max

============

A simple example for what can go wrong in the transition from block  
to pixel coordinates can been seen by considering box coordinates.  
Assume you are given two walk boxes in a V1 games. For simplicity,  
let's assume they are rectangular and we only specify the top left  
and bottom right corner coordinates:

Box 1: (0,0) till (3,5)
Box 2: (4,0) till (6,7)

Note that these two boxes are direct neighbors -- horizontally, the  
first covers "block" 0,1,2,3, while the 2nd one cover 4,5,6.
Translated to pixel level coordinates, we'd get:

Box 1': (0,0) till (24,10)
Box 2': (32,0) till (48,14)

Ooops -- the two boxes are not direct neighbors anymore. That's a  
serious problem for the walking codeFirst source for problem.
You might now say: OK, then don't convert the bottom right  
coordinates like that -- do not just multiply by 8 resp. 2, but also  
add 7 resp. 1. So we'd end up with

Box 1'': (0,0) till (31,11)
Box 2'': (24,0) till (55,15)

That doesn't quite work either. First off, boxes aren't always  
rectangles. Secondly, now in some spots the actor can reach places he  
shouldn't be able to reach (visually).

Variations of this are possible (you could try to extend to the left  
*and* right, for example), but all are just hacks that try to cover  
up the problem, and (at least in my experiments back then) cause new  
problems of their own.