Re: [Bontz-team] sprites

[Chuck]

also i just want to make sure that you know that the pixel perfect collision
detection you want can be quite processor intensive.

how about this, as opposed to having pixel perfect collision detection, can
we just define multiple collision rectangles for each sprite?  i suggest we
possibally try to normalize this by having 3 for each sprite...a top, a
middle, and a bottom collision rectangles.  these rectangles would be
precomputed, for each animation and would be saved in the anim.txt files.

if you decide you absolutely want/need it, i will continue working on it,
although i will be looking for optimizations.

first i think i will compute the top, bottom, left, and right most pixels so
i can shrink down the image to the smallest possible rectangle...i think
this should be manually computed as it could potentially take a good amount
of time to do it at load.  we are currently using 64x64 sprites right?  we
could potentially have to check 4096 pixels for every animation loaded or if
you were really psychotic we would have to do this for every frame within
each animation! mucka has over 24 animation tracks already!  and that is
only standing, walking, and running animations!  so with mucka alone even
though his animation are not yet complete we are already up to 98,304 pixels
we could have to check to compute our rectangle, and this is assuming that
we only check one frame per animation!  if we had to do this for each frame
then we are approaching 200k pixels we have to check.  not to mention this
number will go up as you make the flashing animation i want, and the death
animations, and attack animations, and finally create real standing
animations.  and then we need to load other sprites as well each with an
equal number of animations.  i guess it comes down to how long you expect
our load screens to take?

second if i am to do pixel perfect collision, i am going to make the
assumption that every sprite is unbroken,  meaning that when doing collision
detection i can trace the edge of the rectangle making the colision and if i
find that every pixel along the edge is transparent on one of the sprites
then i need to do no further checking as they have not collided.

third as an optimisation i just thought of while writing this, there should
be a second rectangle defined.  this rectangle will indicate the "core" of
the sprite,  this way i can possibly check to see if the core of two sprites
collide then no matter what i know this would be a collision.







----- Original Message ----- 
From: "Owen Swerkstrom" <address@hidden>
To: <address@hidden>
Sent: Monday, May 05, 2003 6:54 AM
Subject: Re: [Bontz-team] sprites


> I don't really have that information any more than you
> do, but I could go through and check each file.  I'd
> be more tempted to write a quick SDL app to find the
> highest, lowest, leftest and rightest non-transparent
> pixel in a given file though.  Does SDL have any tools
> for collision detection based on the alpha channel?
> That would be ideal, but I can't think of any way it
> could do that very quickly, so it wouldn't surprise me
> if that functionality isn't there.
>
> Anyway maybe for the sake of learning SDL myself I'll
> work up something like that.  Then you could either
> have that code run when a sprite is loaded, or run it
> as a batch and save to a text file that gets parsed
> with those coordinates, whatever you like.  I
> personally find the former a cleaner solution, but the
> latter would actually give more flexibility if the
> "hit range" is smaller during a special move or
> something like that...  *shrugs*
>
>
> --- Chuck <address@hidden> wrote:
> > could you tell me where the edges (top, bottom,
> > left, and right) are for
> > each of the sprites so i can add that to the
> > anim.txt files for the
> > purposes of smarter collision detection?
> > > _______________________________________________
> > Bontz-team mailing list
> > address@hidden
> > http://mail.nongnu.org/mailman/listinfo/bontz-team
> >
>
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com
>
>
> _______________________________________________
> Bontz-team mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/bontz-team
>