Re: [stella] Bounds test?

Subject: Re: [stella] Bounds test?
From: Greg Troutman <mor@xxxxxxx>
Date: Sat, 06 Dec 1997 15:05:16 -0800
Ruffin Bailey wrote:
> 
> >Rescue does both collision tests.  If the 2600 doesn't report the type
> >of collision I'm testing, it just skips along, but if it does, then I
> >bounds test to isolate which sprites/platforms are involved.
> 
> What is a bounds test?  Right now (though it's all on paper), I'm trying
> to determine the best method to figure which copy of several
> "non-co-[horizontally]-linear" copies of plyr1 plyr0 is bumping into when
> a collision is detected.  

You can (and many games do this) check the collision detection register
repeatedly during the drawing of your screen, and know for a fact which
copy of the player graphics was involved in a collision.  Of course,
when you've got a bunch of copies, and you're short of cpu cycles to get
everything properly drawn, extra non-display code like that is
undesirable.  So, when I say "bounds test" I mean I wait until an entire
section of the screen is drawn, before checking the  collision
register.  If it shows I collided, I still don't know which object it
collided with, since it just passed through an area where one of the
player graphic registers (and the missile and playfield graphic
registers) are re-used multiple times.  In that event, I then test to
see where the lander craft actually is in that frame to determine what
it crashed into (or, where the lander's missile is located to determine
which enemy it hit)...  Bob's biggest problem is that he is turning the
player graphics registers for some of the objects OFF during frames
where more than one appear on the same scanline, so a collision with
that flickering object will not be reported during those OFF frames. 
So, the 2600's built-in collision detection is potentially unreliable.  

> Does a bounds test help with that, or only with
> the "plyr0-plyr0" collisons I thought (as in, "I thought, but wouldn't be
> suprised if I was wrong,") Bob was talking about.

I think Bob was talking about missile vs. player collisions.  You don't
need to use the 2600's collision detection to check and see if two
objects happen to be in the same screen space.  He's using the X-Y
coords of his objects and the height and width of them to create a
rectangle, so that he can test if the missile is inside that rectangle
and assume a collision.  The problem with rectangular area comparisons
is that you'll get a match (collision) even though one object inside a
rectangle of another object is not actually touching a lighted pixel of
the object.  Eg. unless the object is perfectly rectangular, collision
detection is prone to slight errors.  Some real arcade games and many
early computer games from the classic era actually implement this sort
of collision detection.  The arcade version of Kangaroo is like that,
but it's not a big problem since the character really fills most of a
rectangular area, and none of the objects it can collide with move
diagonally through the corners of it's rectangular area.  A wildly free
moving game like Bob is doing will require a bit more sophistication to
work right.

How about just describing in more detail how you'd like your game to
work, and maybe we can offer some specific advice?

--
mor@xxxxxxx
http://www.crl.com/~mor/

--
Stella list is Administered by krishna@xxxxxxxxxxxx <Glenn Saunders>
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/stella.html
+-shameless plugs-------------------------------------------------------+
| Stella documentary at http://www.primenet.com/~krishna                |
| Nick's VCS links via http://www.primenet.com/~nickb/atariprg.htm      |
| Write the best game, win framed autographs of famous Atari alumni!!   |
+-----------------------------------------------------------------------+

Current Thread