It occurs to me that even tho the "intersect" function works with the bounding rectangle of an object, and not the actual object itself, "intersect" could nonetheless be useful as a sort of initial screen. If "intersect" doesn't think the two objects intersect, well, they *can't* intersect, right? Thus, use "intersect" to winnow out the wheat (stuff that *might* intersect) from the chaff (stuff that *can't* intersect), and then use your *real* intersection-finding function on the wheat. Like so:
function WhatIntersectz DaList, DerObject # DerObject is the thing you want to find out what intersects with it # DaList is a return-delimited list of all the objects that *might* intersect with DerObject put "" into NuList repeat for each line LL in DaList if intersect (the rect of LL, the rect of DerObject) then put LL into line (1 + the number of lines in NuList) of NuList end if end repeat put NuList into DaList # now we've got a list of all the objects which *might* intersect # which are the real deal? put "" into NuList repeat for each line LL in DaList if ReallyIntersect (the rect of LL, the rect of DerObject) then put LL into line (1 + the number of lines in NuList) of NuList end if end repeat return NuList end WhatIntersectz "ReallyIntersect" is, of course, a separate handler which takes the actual points of a polygon into account when determining what does or doesn't intersect. What's the point of going thru all this rigamarole in the first place? It depends how fast the "ReallyIntersect" code is, as compared to the "intersect" function. I'm assuming that "ReallyIntersect" is going to be appreciably slower than "intersect", in which case it makes sense to use "ReallyIntersect" as little as possible. Hope this helps... _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution