[Scummvm-devel] That pesky CMI walkbox problem... (fwd)

[J.Brown (Ender)]

I think your on the right track here. But does adding in a min/max check
to switch the coordinates in getBoxCoordinates help? I quickly tried it,
and it does indeed seem to fix the box problem...

But there are also two other noticable walkbox problems, and I wonder if
they are related and this is an incorrect, or at least incomplete, fix.

To wit:
  - On entering either the grove where Elaine's statue is, or the Cannibal
Village, for the first time, Guybrush is placed in the wrong starting box.

Also remember that COMI boxes -are- polygons, so the orientation of the
coordinates really -shouldn't- matter. If any of our code does fail
because of this, it is a bug..

 - Ender

   http://www.scummvm.org/   | "Amen! Attempts to eradicate humour from
   http://www.quakesrc.org/  |  our distribution should be ignored with
   http://www.enderboi.com/  |  extreme prejudice" - cjwatson at debian.org

---------- Forwarded message ----------
Date: Wed, 5 Feb 2003 11:51:36 +0100
From: torbjorn.e.andersson at tietoenator.com
To: ender at scummvm.org
Subject: That pesky CMI walkbox problem...

The computer that I can send readable messages to scummvm-devel from is
currently unreachable, so I'll send this directly to you and let you decide
whether or not you want to pass it on to the mailing list.

Something's definitely fishy about the box handling. When you try to pick up
the cup, Guybrush will try to walk to (861, 503).

Walkbox 7 passes the "quick rejection" test, so checkXYInBoxBounds() is
called to test for sure. Box 7 has the following corners:

UL: (750, 533)
UR: (882, 533)
LL: (750, 473)
LR: (882, 473)

I.e. the box is square, and (861, 503) is indeed inside it. The only odd
thing about it is that, from a human perspective, the "upper" and "lower"
corners have switched places.

Unfortunately, checkXYInBoxBounds() doesn't agree. It fails on the first
compareSlope() test.

So either the function is buggy (and I certainly don't understand it well
enough yet to fix it), or it's being used the wrong way. Maybe it *does*
make assumptions about upper/lower and left/right actually meaning what
they say they do. I never had the time to fix the code to ensure that, so
I still don't know what difference it'd make. (It would also be interesting
to see if such a change would affect the MI2 problem where the game would
freeze if it wasn't for the hack in o5_getDist().)

Torbjörn

-- 
TietoEnator Resource Management AB
Persona
Torbjörn Andersson
http://www.rm.tietoenator.com/