[Scummvm-devel] Fixing walking in ZAK and MM (volunteers?)
max at quendi.de
Wed Oct 4 21:55:14 CEST 2006
I just was looking at some old bug reports which reminded me of the
following problem. Maybe somebody is interested in working on a
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
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.
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.
More information about the Scummvm-devel