Re: [pygame] Pixel perfect collision detection sugestion

["John Eriksson" <john@xxxxxxxxxxxx>]

The screen subdivision sorting is that kind of things that is placed under
the "smart design" label :o) A special solution for a special case.

I'm not saying that sorting is all bad...just that you usually don't need
it...and when you need it, you often need some special sorting algorithms
that does the trick for your game.

/John

> I dunno, screen subdivision sorting for moving sprites is usually
> beneficial.  Without it, my engine starts to drag at around 100
> Actors (inherits and extends Sprite).  But you generally only need
> a subdivision by four unless you have tons of tiny sprites.On 9/10/05,
John Eriksson <john@xxxxxxxxxxxx> wrote:
> 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
theperfomance down.What you instead must do when writing a game is to have a
smart design. Atiled background for example, should not be treated as a
collection of
> sprites. The tiles are always in the same (ralative) locations and it's
veryeasy to calculate which tiles your sprite is overlapping. And if
you'rewriting 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
techniqueslike using "hotspots" or as discussed before, using
circles.
> My sugsetion, if we are to implement pixel perfect collision detection is
tostart with a small and simple implementation. We could even start to
justimplement 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?>-- Andrew Ulysses Baker"failrate"
>