Re: A89: FuZiOnZ Clarification
[Prev][Next][Index][Thread]
Re: A89: FuZiOnZ Clarification
I've been thinking about the collision-detection problem over the week-end, and my dad suggested
that we use a box "barrier" around the ship, and then if the barrier is violated, then do the actual
checking for collision. I know that this would slow the game down once you are close to an object,
but this would reduce the collision-detection to a minimum durring the actual game.
I really like your idea about the seperate sprites with one problem- wouldn't it be faster to draw
one large sprite than change coordinates a lot and draw many small sprites?
-Miles Raymond EML: m_rayman@bigfoot.com
ICQ: 13217756 IRC: Killer2 AIM: MRayMan
http://www.bigfoot.com/~m_rayman/
-----Original Message-----
From: Matt Johnson <matt2000@dogtech.com>
To: assembly-89@lists.ticalc.org <assembly-89@lists.ticalc.org>
Date: Friday, January 08, 1999 11:14 PM
Subject: Re: A89: FuZiOnZ Clarification
>I meant Ti-8x calculators, not x86 (too much asm on the brain)
>
>>I'm not sure what this discussion was from, but pixel level collision
>>detection probably is too slow for x86 calculators.. at least not practical
>>if you plan on having more then a few sprites on the screen at once. You
>can
>>use a technique called 'limiting the bounding boxes' which increases
>>accuracy.. or, simply compose the ship of multiple sprites and those
>sprites
>>implement collision detection seperately (i.e. 1 sprite = hull, 2 sprites =
>>wing on each side)
>>
>>>> wouldnt it be even faster to assume they where boxes?
>>>
>>>One problem would be that it would be very odd if you fired at a ship
>>(imagine
>>>those butterfly looking things in level one of Star Fox for the SNES) and
>>you
>>>hit it just past the wing, but it blew up. But then again, odd hit
>>detection
>>>is better than no game. :)