Hi,
> > 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.
She seems to have an Avoider, which could have caused this (triggered by
the collision), so fixing the collision would fix this as well (provided
that my assumption is correct).
> 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.
They look identical to me (relative to the y coordinate).
> > 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 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]
[...]
I believe this is the point in the gfx docs where I stopped commenting.
Anyway, the important thing here is the sig value (20000000 at 0x96e6 on
the heap, which is only slightly incorrect (only the lower 16 bits can be
found there).
> Haines' is 0x96ce. shopwoman is 0x9730. Could you please explain what this
> output means?
v S00011864#96ce [(94,81)(20x44)]V DYNVIEW SORT=2 z=0 seq=-5
| | | | | | | | | |
| | | | | | | | | +- Sequence
| | | | | | | | | number
| | | | | | | | +----- z coordinate
| | | | | | | +------------ Temporal
| | | | | | | order
| | | | | | +-------------------- Widget type
| | | | | +---------------------- VISIBLE flag
| | | | +----------------------------- Widget size
| | | +------------------------------------ Upper left
| | | corner of
| | | the area
| | | covered
| | +------------------------------------------- Widget ID
| +----------------------------------------------------- Serial Nr
+------------------------------------------------------- 'valid'
- valid flag: Check performed during runtime (magic number check)
- Serial number: Used extensively when debugging widgets
- Widget ID: optional, used for port IDs and heap addresses of dynview
objects
- 'VISIBLE' flag: One of several widget flags
- Temporal order: Analyzing the Animate() algorithm yields a partial
order on widgets not easily deductable from its selectors. Factorizing
on this relation gives us three classes of widgets; these we represent
here.
- Sequence number: Number defined by the position in the list passed to
Animate(), this is used as the least relvant factor when sorting
dynviews.
.... (49/0/7)@(104,125)[p:8,c:-1]; sig[20000000@96e6]
| | | | | |
| | | | | +--- Address of the
| | | | | view object's
| | | | | signal selector
| | | | +------------ Copy of the view
| | | | object's signals,
| | | | plus two
| | | | additional
| | | | internal
| | | | signals
| | | +----------------------- Color on
| | | the control map
| | +--------------------------- Color on the
| | priority map
| +------------------------------------ View coordinates
+--------------------------------------------- view/loop/cel
- Priority/Control map values: -1 means 'transparent'.
The signal values are the same as for view objects, except for the two
additional flags mentioned in kernel.h; one is used as a temporary result
(-> updated Animate() algorithm), the other is a very recent hack or
solution (I'm not sure which it is quite yet) to mark views that have been
stopUpdated(), and this is 0x20000000.
> 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.
I'm sorry that I don't keep the documentation up to date with these
changes. I only have the usual excuses (no one cares; not enough time;
"it's probably just a temporary change"; we're too far behind already, so
no one can understand it anyway; source code is more precise and
much easier to read) to 'explain' this, I assume using some tool to
generate documentation from the sources would be called for (particularly
for the constant values). I must apologize for not keeping the
documentation up to date
> > 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?
Sorry, I meant the list of haines::signal in temporal order, starting at
his first appearance and leaving out duplicates in between. Doing this
manually would be rather painful.
BTW, thanks for going through all the trouble of debugging this!
llap,
Christoph
