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

Re: [pygame] Pixel perfect collision detection sugestion



Yep, using boundary lines is another way to go.

It's especialy effective to use this technique if you rotate and/or scale
your sprites in runtime (using OpenGL, Direct3D or something).

Then you just have to perform the same transformations on the collision
detection data as for the image.

The actual collision detection can be rather expensive though...especially
if you're not carfull with the accuracy setting ;-)

/John

>
> ClanLib has a pretty fancy collision system, might be worth checking out:
> http://clanlib.org/docs/Overview/collision_detection.html
>
> On 9/11/05, John Eriksson <john@xxxxxxxxxxxx> wrote:
> > *smile*  There are as many aproaches as games and game developers.
None of
> > them are wrong as long as they make the game experience tick.
> >
> > When using pixel perfect you must, in many cases also have a
> > different/smaller hitmask and not generate it from the sprite image
> > directly. Say for example a rocket... you don't want the tail flames
to
> > cause a collision, so the hitmask must be set by using a separate
image.
> >
> > I really dont belive that rectangle collisions should be replaced by
pixel
> > perfect...but both of them should exist.
> >
> > /John
> >
> > > Not so.  You'll find in the majority of games, the
collision box
> > > is slightly smaller than the in-game sprite for the
player.  For
> > > an extreme example, try playing a Japanese shmup, where the
hit-box is
> > > limited to the player's cockpit.
> > >
> > > When I wanted to modify the rect collision system in my engine,
I found> > it rather easy to decouple the main rect and substitute my
own
> > > arbitrary rect (which was positioned at the
"feet" of the
> > sprite, same
> > > width, half as tall) and collision functions using these new
rects by
> > > basically overloading the default classes and
functions.  So, I'm
> > > guessing that regardless of the final approaches, they should
all be
> > > abstracted that switching between them should remain this
painless.
> > > -- Andrew Ulysses Baker"failrate"
> > >
> >
> >
>
>
>
>