Re: [pygame] Pixel perfect collision detection sugestion

["John Eriksson" <john@xxxxxxxxxxxx>]

Yo,

> "Then again, it may be overkill?"
In my experience you'll have to have a really high amount of sprites before
you'll need to sort them. In most types of games the sorting only drags the
perfomance down.

What you instead must do when writing a game is to have a smart design. A
tiled background for example, should not be treated as a collection of
sprites. The tiles are always in the same (ralative) locations and it's very
easy to calculate which tiles your sprite is overlapping. And if you're
writing a shoot'em up whith alot of flying bullets all over the screen, it
might not be necessary to check more than one singe pixel for each bullet
(depening on the bullet size of course). There are also other techniques
like using "hotspots" or as discussed before, using circles.

My sugsetion, if we are to implement pixel perfect collision detection is to
start with a small and simple implementation. We could even start to just
implement it in python and then convert it to C. The most important thing
anyway to start with is to get the API right.

Best Regards
/John Eriksson

> I good KD Tree library might help. These are trees that help find
> nearest neighbors between a large set of objects. The tree itself takes
> time to construct, but once you are dealing with enough objects it
> becomes a quicker way to find objects within a radius of other objects.
>
> This also means you'll need to know the maximum size of the sprites, so
> you know when to stop searching the nearest points. Then again, it may
> be overkill?
>