Mail Archives: djgpp/1997/02/08/21:50:40
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
- Raw text -