Collision detection: A comparison

Dar Scott dsc at swcp.com
Fri Oct 4 12:38:00 EDT 2002


On Thursday, October 3, 2002, at 04:38 AM, malte brill wrote:

> So first check with intersect function, if intersec=true then check with
> pixel method for the overlapping parts of the two objects?
> That seems to be a good thought.

Yes.

> It really sounds as if it might be enough to check exerpts of the maskdata,
> but I still got no idea how to compute them.

It is probably possible to use maskdata, though it might depend on the type 
of image.  I have not used it.

I have used the alpha bytes from imagedata.  That might depend on the type 
of image, too; maybe I was lucky in it working for me.

I would start with making a function that given an imagedata string, X & Y 
pixel coordinate within that image and the width of the image returns the 
character containing the alpha.  I say char instead of number incase you 
can get by without the number and compare the char directly.  I think there 
are some clues to working with imagedata at Ken Ray's site.

Test that by displaying the charToNum() of the returned value for each 
pixel of a tiny image.  Format it so each image row is one line.

You can build your initial collision detection from that.

(I say "initial" because you will want to optimize over row comparison 
later.  After you optimize you should have only two additions and one 
comparison per cycle for iteration.  This does not include the pixel 
comparison; this is just what it takes to go from one pixel to another in 
the two row segments being compared.)

You have three coordinate systems to convert among.  That of each image and 
that of the card they are on.  It may be easiest (to start with) to work in 
the card coordinates and convert from that.  When you optimize, you might 
want to change that.

So, make another function that uses the one above.  It also has the 
location of the image as args and the X and Y are in the card coordinates.
   You can now get corresponding pixels of two images.

Then to look for a collision iterate over the pixels in the overlapped 
portion using card coordinates.
To check for whether the two pixels overlap, you might see if both are 
after 'z', a trick to see if both values are greater than 122.  If you don'
t have soft edges, then your alphas will be 0 or 255, so this will work.  
An alternative would be to multiply the charToNum() of each and see if that 
is greater than 16256.

In card coordinates, I would guess the overlapped rectangle (in card 
coordinates) is that with the max top, min bottom, min left and max right 
of the rectangle (property) of the images.  Test this function; I may have 
goofed.

So... Build from the bottom.  Test as you go.  Worry about optimization 
after you see the big picture.
If, after optimization, this is too slow, then consider the subrects we 
talked about.

Dar Scott




More information about the Use-livecode mailing list