On Tue, 25 Dec 2001, Christoph Reichenbach wrote:
> > I have updated the screenshots on my website from the SSCI debugger. I
> > have noticed a pattern: the horizontal coordinates (x, brLeft, brRight,
> > etc) for both haines and shopwoman seem to be offset by -50 or so.
>
> How so? At the very least, brRect and nsRect are consistant (relative to
> the coordinates) between SSCI and FSCI. It seems that you simply
> inspected/dumped the view objects when they were at a different position,
> which would explain the difference.
They don't follow the same path in FSCI as in SSCI, that's why the
coordinates are slightly different. What I did was step in the SSCI
debugger until shopwoman was at x of 82, which is where she stops in FSCI.
The y coordinate is different, which doesn't make sense. They seem to
deviate from their path sooner in FSCI than SSCI.
Sorry, I had misread the lsRect for shopwoman as the brRect. The lsRect is
the one with odd values in FSCI that do not match SSCI. the brRect and
nsRect's top and bottom are slightly off.
> The shopwoman collides with haines; the reason for this is that the area
> checked for haines is much higher than his brRect. The only reason I'm
> aware of that could cause this would be that haines bears the mark of the
> stopUpdate()d, which is stored in the dynview list (please run
> 'gfx_print_dynviews' on the debug console).
>gfx_print_dynviews
v S000114ff[(0,10)(320x190)]VCI SORTED_LIST viszone=((0,10),(320x190))
--dirty:
--contents:
v S0001185f#9792 [(-40,118)(117x36)]V DYNVIEW SORT=0 z=0 seq=0
(54/0/1)@(18,154)[p:11,c:-1]; sig[20001804@97aa]
v S00011866#95a2 [(43,120)(27x38)]V DYNVIEW SORT=0 z=0 seq=-7
(51/4/0)@(56,158)[p:12,c:-1]; sig[20005014@95ba]
v S00011863#95f0 [(228,176)(25x18)]V DYNVIEW SORT=0 z=0 seq=-4
(75/5/0)@(240,194)[p:14,c:-1]; sig[20004814@9608]
v S00011865#9730 [(70,71)(24x45)]V DYNVIEW SORT=2 z=0 seq=-6
(2/0/3)@(82,116)[p:7,c:-1]; sig[20000400@9748]
v S00011864#96ce [(94,81)(20x44)]V DYNVIEW SORT=2 z=0 seq=-5
(49/0/7)@(104,125)[p:8,c:-1]; sig[20000000@96e6]
v S00011862#963a [(228,138)(7x3)]V DYNVIEW SORT=2 z=0 seq=-3
(54/3/3)@(231,141)[p:13,c:-1]; sig[0012@9652]
v S00011860#3002 [(224,157)(13x45)]V DYNVIEW SORT=2 z=0 seq=-1
(0/3/0)@(230,201)[p:14,c:-1]; sig[2002@301a]
v S00011861#ba06 [(390,356)(21x45)]V DYNVIEW SORT=2 z=0 seq=-2
(20/0/0)@(400,401)[p:14,c:-1]; sig[0002@ba1e]
Haines' is 0x96ce. shopwoman is 0x9730. Could you please explain what this
output means? I don't see any way to tell any of these are "stopUpdate()d"
from the output, or by looking at the source for the
_gfxwop_some_view_print() function. Looking at the definition for
gfxw_dyn_view_t helps a little, but doesn't give me the big picture view
of how this could/would relate to the bug.
> If this is the case, we have to start looking for a difference between him
> and the motivator unit- the easiest difference would, of course, be that
> he moves, which we can check for relatively easily, but there might be
> some other, unusual constellation of haines::signal flags. I think we can
> safely patch around this by checking for movement ATM, until a list of
> values of 'haines::signal' in correct temporal order can be assembled more
> easliy.
The signal selector for haines appears to be 0 in SSCI.. unless I
misunderstood you?
> Good night and Merry Christmas,
To you and the rest of the FreeSCI team as well :)
--
http://www.clock.org/~matt
