Re: [Bontz-team] sprites

[Chuck]

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


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

we could however write a program that will search an image for these values
and automatically write them to a file, but i would not want to have the
game itself automatically find them.  at least unless i find that we can do
this extremly quickly for each animation that needs it.


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

the main game will still need collision detection, but possibly not as
important or as complex as some of the minigames.
i foresee though that we will use collison detection in the game.  i think
the above suggestion that i made will be the most efficient and accurate
method for all the minigames and the main one.  we don't nececarily need to
have a top middle bottom, just 1 or more overlaping rectangles would work,
and then if there is an overlap of any of the rectangles between two sprites
then that would be considered a collision or if we really wanted pixel to
pixel collision detection, we can then at the very least use this to narrow
our search significantly.  as for handling a character crouching, that is
why we should define these boxes for each animation.  as i would consider
crouching a different animation than standing, or walking.  as you can see
it is quite possible for different animations to have different collition
rectangles and this should all be defined in the anim.txt file for fast
loading. as well, if maybe we wanted to make the battle system do damage
based on where the character is hit, we can also use this multiple collision
rectangle system work at detecting where the sprite was hit by an attack.
like maybe a hit in the foot will do less damage than a hit in the
head...although it doesn't really sound like we need this type of collision
resolution  for anything right now.  but who knows what mini game or how we
decide to setup the battle system in the future...

i think i can see a bontz  smash brothers type fighter in the future in
which this type of collision detection could be potentially useful.





>
> > 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.  :^)


which is why i try to keep you busy so you don't have time to ask annoying
questions :-P

besides, what always makes a big game fun and replayable is by having a lot
of variety, and that is what the minigames do.  so we clearly need
minigames, and for these minigames to work, we need collision detection.



>
> > 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
>
>
> _______________________________________________
> Bontz-team mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/bontz-team
>