Path: chuka.playstation.co.uk!news From: "Alex Herbert" Newsgroups: scee.yaroze.programming.2d_graphics Subject: Re: What do'you mean I have to brush up on me maths! Date: Wed, 14 Jul 1999 22:17:10 +0100 Organization: PlayStation Net Yaroze (SCEE) Lines: 48 Message-ID: <7miu76$bjc1@chuka.playstation.co.uk> References: <7ko1jf$33u25@chuka.playstation.co.uk> <376fbd21.251404588@news.scea.sony.com> <7lkucs$ko217@chuka.playstation.co.uk> <7lnteg$i9a1@chuka.playstation.co.uk> <37823145.682258342@news.scea.sony.com> <7mah71$t1v6@chuka.playstation.co.uk> <378a1a59.1200158692@news.scea.sony.com> <7mioup$t1v11@chuka.playstation.co.uk> NNTP-Posting-Host: 212.56.110.165 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Rikki Prince wrote in message news:7mioup$t1v11@chuka.playstation.co.uk... > > Surely there's a maximum amount that can be entered, as the input is > calculated from the position of a player, which is probably on the screen. > You could probably work out the maximum input for the inverse tan, by taking > the largest point on the screen, and using it in the calculation for the > input. However, you'd have to be certain that the maximum screen > width/height will be the maximum of values used in the input. > Hi all, It's not quite that simple. What if dx is 0? In this case dy/dx = infinity. Also, half of the time dy will be closer to 0 than dx, so dy/dx will result in a value between 0 and 1 (or -1) which is not much good when we're dealing with integer maths. dy can be shifted left a few bits for greater precision but for each extra bit of resolution, the size of the lookup table would have to be doubled. The solution is to have a lookup table which only covers 45 degrees and pass dx and dy to the function separately (i.e. before dividing). Then take the absolute values of dx and dy (remove the sign) and divide the higher value (shifted left a few bits for resolution) by the lower. This value can then be used as the index to the lookup table. The result from the lookup then has to be adjusted depending on whether dy was divided by dx, or dx was divided by dy, and depending on what the signs of dx and dy were originally. Will this be quicker than a square root? Probably, but the square root method eliminates the need for sin/cos lookups and overall I'm sure there won't be much in it. If you're interested, I have programmed a pretty fast square root function in assembly which I'll be happy to share. Also, I remember that Craig Graham had a nifty function for approximating the distance between 2 points which may be suitable for this application. I think it was called Manhattan distance or something. Anyone? Craig? Anyway, hope this all helps. Herbs