From: Kevin Hill <khill AT gwi DOT net>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Collison detection fo Action game
Date: Sat, 08 Feb 1997 14:48:41 -0500
Organization: none
Lines: 53
Message-ID: <32FCD899.7171@gwi.net>
References: <855142026 DOT 12716 AT dejanews DOT com> <vgpI$hAr7O+yEwGt AT talula DOT demon DOT co DOT uk> <5dcgr6$il AT sunsystem5 DOT informatik DOT tu-muenchen DOT de>
Reply-To: khill AT gwi DOT net
NNTP-Posting-Host: sanpc19.gwi.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Christian Tamasiu wrote:
> 
> 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.
> 

This would be WAY too slow if you were checking bits in the VGA memory,
probably a little better if you were to draw everything to a buffer in
main RAM and do your checking there, then copy the entire buffer to the
screen afterward.

						Kev