Re: [Bontz-team] sprites

[Owen Swerkstrom]

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

I know, that's what I meant about figuring there
wasn't any efficient way to do it.  But an algorithm
that, upon loading each sprite/sprite set, looks for
the highest/lowest/leftest/rightest nonalpha pixel and
defines that as its range (maybe plus or minus a
global fudge factor for leniant collisions?)

> 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.

Sure, we could do that.  What's your reasoning with
top/middle/bottom?  (I'm just curious)  Also do we
want to take into account something exotic where say a
character crouches down so the hit detection becomes
only half as tall, something on a per-frame or
per-state basis?  (not trying to be difficult, the
main game won't even need collision detection, just
curious)

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

I can't imagine any reason we need pixel-perfect slow
hit detection.  I was just curious if SDL had such a
thing built in.  QT does, but it makes a little more
sense there as there might be funny-shaped icons being
clicked etc.  A general media layer built for speed
wouldn't have much use for such functionality.

> 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?

do it the fast way.  As someone who's played Nintendo
all his life I hate it when games stop everything and
say "Loading".  :^)  Remember I don't personally care
much about collision detection, this minigame's all
you, pretty much.  I just ask annoying questions.  :^)

> 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.

My brain hurts.  :^)  Don't worry about it.  Set edges
are good.  It's only a minigame.  :^)  I'm trying to
think of what ability in the main game will corespond
with this one, I think all Mucka's hallucinations
should become assets he can use...  perhaps this is
where the pink elephant comes in, that could be the
boss of this shooter

> 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.

Let's keep it pretty un-fancy.  Unless we think we'll
be re-using this code for other minigames etc, I don't
see any reason to make a superbly-flexible, elegant
hit-detection system.
"Camelot!"
"Camelot!"
"Camelot!"
"it's only a model."


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com