Re: RE: Space Wars

I do realize that I'm oversimplifying here, but if the problem is that the 6502
takes too much time to do multiplication (because of a lack of a multiply
instruction) why don't you try using a version that DOES have a multiply
instruction? There must be one out there somewhere. At last look Rockwell and
Western Design Center were still making 6502 variants. In fact WDC had a 16-bit
version.

I know I'd like to play with the Scenix also, but going with something that
would just plug into an existing processor socket (albeit it MAY need an adapter
to do it) is worth considering.

jeff hendrix wrote:

> I do bounding box checks first (this is a must). That's all I had it doing
> at first, but there's no way to determine which "part" of the ship got hit,
> so I have to check the segments.
>
> Shot to ship checks are just fine. One line (with endpoints at the old shot
> and new shot positions) checking against the segments of the ship.
>
> The problem is when both ships get within each others bounding boxes. Then I
> have to check each segment of the first ship against each segment of the
> second ship. I originally had 9 and 11 segments for a total of 99 checks and
> each check requires several multiplies, and since the 6502 doesn't have a
> multiply, it takes several hundred lines of instruction to do each check.
> (I've since cut the bounding segments down to 6 and 8, it's not as accurate,
> but it's a little faster, but still not fast enough)
>
> I had also hoped to eventually write a 4 player space wars, but using my
> current collision detection, it would probably bring to game to a halt if
> all 4 ships were colliding at the same time.
>
> I've posted this before, but if anybody has a suggestion on how to spead up
> accurate collision detection, please let me know.
> I'm implementing the following formula for each segment check (re-written in
> assembly, of course, for a total of about 300 lines of code. Remeber the
> 6502 only has add, sub,and shift)
>
> x1,y1 - segment initial position
> x2,y2 - segment new position
> x3,y3 - last point from ship used to check collision
> x4,y4 - new point from ship used to check collision
> a1=y2-y1
> b1=x1-x2
> c1=x2*y1-x1*y2
> r1=a1*x3+b1*y3+c1
> r2=a1*x4+b1*y4+c1
> if r1 & r2 !=0 & have same sign, they don't intersect
> a2=y4-y3
> b2=x3-x4
> c2=x4*y3-x3*y4
> r1=a2*x1+b2*y1+c2
> r2=a2*x2+b2*y2+c2
> if r1 & r2 have same sign, they don't intersect
>
> This works find for shot collision detection (I'm using the old shot
> position and the new shot position for the line endpoints), but it's way too
> slow for ship to ship.
>
> -jeff
>
> -----Original Message-----
> From: Paul Kahler [mailto:phkahler@Oakland.edu]
> Sent: Thursday, February 03, 2000 7:36 AM
> To: vectorlist@synthcom.com
> Subject: Re: VECTOR: RE: Space Wars
>
> > >Ya know, I am wondering why a co-processor is needed for Space War on
> Space
> > >Duel hardware, since SD manages to do the colision detection, AND keep
> all
> > >the other objects moving.
> >
> > Not to answer on Jeff's behalf or anything, but he's doing real
> > point-on-line collision checking which is a fair amount of math. Space
> Duel
>
> I too am wondering why a co-processor is needed. To say "he's doing real"
> hard stuff doesn't justify adding a co-processor. Just don't do such an
> elaborate collision detection. Here's a suggestion:
>
> 1) Do a bounding box check first - there should not be more than 1 or *2*
> bullets within the box at any time. I assume he's doing this already.
> 2) For each bullet within the box, rotate/translate the bullet into
> ship coordinates and check against a table representing the outline
> of the ship. Ya, the rotate will take 4 multiplies, but that's gotta
> be faster than anything dealing with each line :-)
>
> <ramble>
> BTW, as for the scenix. I was a little let down that they cloned the PIC
> '54 architecture. I wrote a chess program for the PIC16C63 that just needs
> a little more RAM and stack than the scenix. It takes 30-60 seconds to make
> a move and can look up to 6 moves ahead. I've been meaning to wire up a
> PIC 16C923 with built in LCD controller to run it :-) No doubt this is the
> smallest chess engine in the world (written in C yet).
> </ramble>
> --
> ___ __ _ _ _
> | \ / \ | | | || | phkahler@oakland.edu Engineer/Programmer
> | _/| || || |_| || |__ " What makes someone care so much?
> |_| |_||_| \___/ |____) for things another man can just ignore. "
> -S.H.
> ---------------------------------------------------------------------------
> ** To UNSUBSCRIBE from vectorlist, send a message with "UNSUBSCRIBE" in the
> ** message body to vectorlist-request@synthcom.com. Please direct other
> ** questions, comments, or problems to neil@synthcom.com.
> ---------------------------------------------------------------------------
> ** To UNSUBSCRIBE from vectorlist, send a message with "UNSUBSCRIBE" in the
> ** message body to vectorlist-request@synthcom.com. Please direct other
> ** questions, comments, or problems to neil@synthcom.com.

--
Windows:
32 bit graphical interface for a
16 bit patch for an
8 bit operating system written for a
4 bit processor by a
2 bit company that can't stand
1 bit of competition.
---------------------------------------------------------------------------
** To UNSUBSCRIBE from vectorlist, send a message with "UNSUBSCRIBE" in the
** message body to vectorlist-request@synthcom.com. Please direct other
** questions, comments, or problems to neil@synthcom.com.