Re: [pygame] Game idea revised

["Bob Ippolito" <bob@xxxxxxxxxx>]

On 2/28/07, Charles Joseph Christie II <sonicbhoc@xxxxxxxxx> wrote:
> On Wed, 28 Feb 2007 14:27:45 -0800
> "Bob Ippolito" <bob@xxxxxxxxxx> wrote:
>
> > On 2/28/07, Charles Joseph Christie II <sonicbhoc@xxxxxxxxx> wrote:
> > > On Wed, 28 Feb 2007 10:55:30 -0800
> > > "Bob Ippolito" <bob@xxxxxxxxxx> wrote:
> > >
> > > > On 2/28/07, Kordova <kordova@xxxxxxxxx> wrote:
> > > > >
> > > > > On Feb 28, 2007, at 8:27 AM, Charles Christie wrote:
> > > > >
> > > > > > This idea seems more and more feasible, and better for pygame,
> > > > > > every time I think about it, and my previous idea of making a
> > > > > > danmaku shoot-em-up game out of this typing thing gets less
> > > > > > savory due to the speed and accuracy limitations of python
> > > > > > (which isn't exactly a bad thing, it's easy to program in for
> > > > > > a newbie like me).
> > > > >
> > > > > I do not know what danmaku is (actually thanks to google I
> > > > > think I now do), but I have had success at work and at home
> > > > > with intensive 3d applications written primarily in Python. If
> > > > > you feel you are able to develop this and are interested in
> > > > > doing so, you should try it. In my experience most complaints
> > > > > against Python tend to be based on poor design and/or
> > > > > implementation of algorithms rather than the language running
> > > > > dog slow. (And you can make the plunge into C extensions or
> > > > > whatever if it really becomes an issue.)
> > > > >
> > > >
> > > > Python having "accuracy limitations" seems very suspect as well.
> > > > Where the heck did that assertion come from?
> > > >
> > > > -bob
> > >
> > > A tutorial on the pygame website says that you shouldn't try to get
> > > pixel perfect hitrect detection. Wouldn't that mess with the game's
> > > accuracy?
> >
> > That's a general rule of game programming; doing bounding rects or
> > circles is a LOT faster than comparing swaths of pixels. It's possible
> > to do it with pixels in pygame if you really want to, and I'm pretty
> > sure I've seen extensions that do exactly that. You still need to
> > design for bounding rect or distance based collision detection in
> > *any* environment even if doing pixel based collision in order to
> > decide which things are worth comparing.
> Bounding rect? you mean like something that surrounds an object and
> tells if the two bounding rects touched? That's what I thought he meant
> by pixel perfect detection. Oops. ^_^;;

Pixel perfect detection typically means that you're actually comparing
a bitmap mask of two sprites, to see if the actual pixels overlap.

Comparing rectangles or circles is a lot cheaper than individual
pixels. You can check the pixels *after* you've found a collision in
the rectangles (which means they're at least very close to touching
visually), but usually you don't have to bother.

-bob