Hi, [Accumulator is 1 in Sierra SCI, 0 in FSCI]
[...] > Call stack (current base: 9): > 0:[ffffffff] CB1::replay() > obj@0eea pc=0b7d sp=6338 fp=6338 > 1:[0] Game::replay() > obj@0eea pc=57a6 sp=633c fp=633c > 2:[1] CB1::doit() > obj@0eea pc=0cab sp=6344 fp=6340 > 3:[2] Game::doit() > obj@0eea pc=5841 sp=6348 fp=6348 > 4:[3] kAnimate(7924, 0001) > 5:[4] ego::doit() > obj@0684 pc=4eab sp=6352 fp=6352 > 6:[5] Act::doit() > obj@0684 pc=2323 sp=635c fp=6356 > 7:[6] MoveTo::doit() > obj@aada pc=776c sp=636c fp=6360 > 8:[7] kDoBresen(aada) > 9:[8] ego::canBeHere() > obj@0684 pc=2574 sp=6378 fp=6374 > > > > I can only think of two cases where a 'ret' would (implicitly) cause the > > accumulator to change: > > a) if a varselector read is on the stack > > b) if the 'ret' terminated a vm call from below a kernel function > > It looks like the ret terminated the kDoBresen, but I could be wrong. It's very likely you're right. > There is > a list gotten from cast::Elements that might be worth investigating, but how > do I see the key/value pairs in Sierra SCI's debugger? If you are on heap position n, the key and value are at n+4 and n+6 (I'm not certain which is where, but it doesn't matter because they seem to be identical in all cases). In this case, Sierra SCI collides with an obstacle, whereas FreeSCI doesn't. Could you do the following, please: 1) Compare the object being moved before and after DoBresen is called 2) Check for whether the view/loop/cel values being used are valid (they probably aren't). Note that there may be insignificant differences in the cels; in that case, please check this more than once (just the cel values, but remember not to walk the same path you used last time). One theory that comes up is that CanBeHere might be trying to calculate the collission before view/loop/cel have been clipped. llap, Christoph
