Re: [pygame] Pixel perfect collision detection sugestion

["John Eriksson" <john@xxxxxxxxxxxx>]

Back in the 80's you really needed those hardware sprites to get perfomance.
Problem was that you only hade 8(??) of them and they couldn't be as big as
you sometimes wanted them to be.

Today, there are game libraries that have the same type of easy to use
sprites...but...then you also give up some control.

/John

> 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
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"
>
> -- Science is open source religion
>