From:	tamasiu AT informatik DOT tu-muenchen DOT de (Christian Tamasiu)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Collison detection fo Action game
Date:	6 Feb 1997 11:55:18 GMT
Organization:	Technische Universitaet Muenchen, Germany
Lines:	45
Distribution:	world
Message-ID:	<5dcgr6$il@sunsystem5.informatik.tu-muenchen.de>
References:	<855142026 DOT 12716 AT dejanews DOT com> <vgpI$hAr7O+yEwGt AT talula DOT demon DOT co DOT uk>
NNTP-Posting-Host:	hphalle9d.informatik.tu-muenchen.de
Originator:	tamasiu AT hphalle9d DOT informatik DOT tu-muenchen DOT de
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

In article <vgpI$hAr7O+yEwGt AT talula DOT demon DOT co DOT uk>, Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk> writes:
|> 
|> One of the simplest and fastest is to model each object as a circle.
|> Given the centre points of two objects (x1,y1 and x2,y1), and their
|> radius (radiii? what's the plural?) r1 and r2, they have collided if
|> sqrt((x1-x2)*(x1-x2) + (y1-y2)*(y1-y2)) < sqrt(r1*r1 + r2*r2).
|> 
|> Handy tip: avoid square roots: they are slow. Since all you need is the
|> result of the comparison, rather than the actual values, you can just
|> compare the squares and leave out both calls to sqrt().
I'll try this one.

|> If true pixel-perfect testing is needed, one of the fastest approaches
|> is to pregenerate a monochrome mask for each sprite, containing one bits
|> for the pixels that are set and zeros for the ones that aren't. To test
|> two objects for a collision, line up these bitmasks depending on the
|> relative positions of the sprites (this involves a lot of shifting and
|> can be a big pain to get right), and then bitwise-or the two masks
|> together. If the resulting value is non-zero, the objects have collided.
|> This technique lets you check 32 pixels with each test, rather than
|> having to laboriously loop through every single pixel in the sprite...
|> 
|> /*
|>  *  Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
|>  *  Ghoti: 'gh' as in 'enough', 'o' as in 'women', and 'ti' as in 'nation'.
|>  */

Many thanks for the help. What I thought of was to split the 256 colors in a
lower 128 which do not cause a collision and a higher 128 which cause a
collision, which are used for all the objects.
While blitting the object to the screen via a modified draw_sprite, 
I could test the highest bit of the background. If it is set a collision would
have happend. I could then browse through the object-list (e.g. by the circle
method) and find out which object caused the collision. If no object is found in
the list, a collision with the background has happend. 
Using this method I guess I would get a very accurate result, and could also
detect a collision with background objects, and it still would be quite fast.

Is this method any good? I guess it would not be too hard to rewrite the
draw_sprite routines to return if a collision has happend using this method.
Is this a good approach or much to slow?

Chris.
 

- Raw text -