[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Pixel perfect collision detection sugestion



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 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?
>




--
Andrew Ulysses Baker
"failrate"