From: pmonks AT iname DOT com (Peter Monks)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Collision Detection
Date: Tue, 29 Apr 97 02:11:09 GMT
Organization: Financial Market Software Consultants pty ltd
Lines: 27
Message-ID: <5k3lbt$2es_002@fmsc.com.au>
References: <MPG DOT dcddb78f470c89c98968a AT news DOT demon DOT co DOT uk> <Pine DOT SV4 DOT 3 DOT 94 DOT 970428125700 DOT 28102C-100000 AT aludra DOT usc DOT edu>
NNTP-Posting-Host: gw.fmsc.com.au
Cache-Post-Path: clark.fmsc.com.au!unknown AT sleepy DOT fmsc DOT com DOT au
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

In article <Pine DOT SV4 DOT 3 DOT 94 DOT 970428125700 DOT 28102C-100000 AT aludra DOT usc DOT edu>, rellwood <rellwood AT aludra DOT usc DOT edu> wrote:
>
>A third way is to use bounding circles instead.  I have nevery actually
>tried this, but I suppose it could be implemented easily enough using good
>old Pythagorian Theorum, and just measure the DISTANCES between the two
>sprites.  If the result is smaller then a certain threshold, you have a
>collision.  This is a bit more accurate then bounding boxes, but it is
>somewhat slower because you have to compute square roots. 

Actually, you can skip the square root operation by just comparing the 
distances *squared* between objects, rather than the actual distance.  I 
think this makes this approach even faster than the bounding box method.  
Don't quote me in this, however, since I haven't actually tested whether its 
faster or not!

Note that this approach still isn't pixel-accurate, but if your sprites are 
generally circular, it will yield better results than bounding box detection.

Cheers,
Peter


----------------------------------------------------------------------
Peter Monks                    http://www.geocities.com/Yosemite/4455/
pmonks AT iname DOT com
pmo AT fmsc DOT com DOT au
Peter_Monks AT australia DOT notes DOT pw DOT com