Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com From: Scott Cartier Newsgroups: scea.yaroze.programming.2d_graphics Subject: Re: Algorithm to orbit? Date: Mon, 04 Aug 1997 20:29:25 -0700 Organization: SCEA Net Yaroze News Lines: 20 Message-ID: <33E69E15.75F8@concentric.net> References: <01bca03a$5c9d6ee0$8bf135ce@jjustice.iquest.net> <33E4E1EE.7CE0791A@ix.netcom.com> <01bca043$beb64300$8bf135ce@jjustice.iquest.net> <01bca04f$83feb6a0$8bf135ce@jjustice.iquest.net> Reply-To: dsyaroze@concentric.net NNTP-Posting-Host: ts020d19.cup-ca.concentric.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0C-GZone (Win95; I) I see why this is so tricky. Lets say your tank doesn't move, but rotates about its center. Since the turret is not on the tank's center, but say X pixels from the center, it could be anywhere on the circle of radius X with its center on the tank's center. Did I get that right? If so, I don't see an easy way to do it (at least with the library routines). Without thinking too hard - something I'm good at - I would make up a quick 360 entry table to represent the turret's offset relative to the center of the tank at every angle the tank could be at (if it can move in increments less than 1 degree then you're talking about more table entries). To save space you could cut that table to 1/8 it's size and play tricks with swapping X-Y values, and negating X and/or Y values. I have a similar table for my game. Of course if you need the speed then you'll probably want the full table. Anyway, enough rambling. Scott