Re: [pygame] Pixel perfect collision detection sugestion

[Chris Smith <maximinus@xxxxxxxxx>]

Not everyone is just after pixel perfect collision. My current project
would really benefit from sprites that animate automatically (though I
can see the amount of work this would be).

I remember sprites from the 8-bit world, where they automatically
overlayed themselves on top of video ram. You just generally set a
pointer to the image to use, and then x+y positions, without worrying
about the drawing. It kinda amazes me that in 1982 I had this
technology but in 2005 I don't. I'd love to see that kind of ease of
use, together with pixel collisiojn detection, in my fav game library.

On 9/10/05, andrew baker <failrate@xxxxxxxxx> wrote:

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"

-- 
Science is open source religion