Checking the distance Between 2 points?
BlitzMax Forums/BlitzMax Programming/Checking the distance Between 2 points?
| ||
| How do i check the distance between 2 locations on the screen? |
| ||
Assuming by locations on the screen, you mean in 2d only, like this :xd = x2-x1 yd = y2-y1 Distance = SquareRoot(xd*xd + yd*yd) |
| ||
| If you are just going to be compareing distances, you dont need the sqr |
| ||
| That's perfect, Thanks. :) Any news on TV3D? Sorry to keep pestering. :) |
| ||
| If you are just going to be compareing distances, you dont need the sqr How would you do it H&K? Just to give you an idea of what I'm doing, I want the distance between to pixels on screen (2D). If the distance is within a certain amount I want the 2 points deleted. |
| ||
| so you are just doing a comparison so from gabs Comparitive = Comparative^2 then in all the compares If (XD*XD+YD*YD)<Comparitive all you are doing is squareing the comparitive once, rather than finding the square root each time |
| ||
| I think i get it. I have a Type with fields "XLoc & YLoc". I have setup a method to check the distance. Would I do this: Mthod CheckDistance() DistanceBetween = DistanceBetween^2 If (Xloc*Xloc + YLoc*YLoc) < DistanceBetween - 10 DeleteStuff!!! End Method. Would that be right? |
| ||
| If the "certain amount" you're checking if the distance is within is constant then square that and do what H&K suggests. Unless you're doing it a few thousand times a second, I'm not sure it'll notice, but it won't hurt. Any news on TV3D? Sorry to keep pestering. :) They originally said it would be fixed by the end of the week. They've marked it fixed on the bugtracker. I asked when we can expect a new build to be uploaded. I've received no response. New builds tend to be uploaded on a weekend, so I wouldn't expect anything before at least a week. Which means another week I can't do any real work. No need to apologize for pestering. I only wish I could do something about it, but the GCC build seems to have a very low priority at the best of times. Heck perhaps it's me that's the problem. They didn't even acknowledge the bug report until someone else posted about it too. And even then they asked for a code sample which demonstrated it.. two days after I had sent them one. Maybe you need to fire me and get someone the TV3D devs like to be in charge instead ;) |
| ||
| Don't get it. :/ |
| ||
TestDistance = 25 '<---25 pixel test distance
TestDistance = TestDistance * TestDistance 'square the test difference since we *aren't* taking
'the square root of the distance calculated below
xd = x2-x1
yd = y2-y1
Distance = xd*xd + yd*yd
'now, do your test
If (Distance < TestDistance )
dostuff
Endif
|
| ||
| Amon - I think H&K has confused you. To get his 'addendum' out of the way first, he was basically saying this. Imagine you have two ships, and a planet. You want to find out which ship is nearest the planet, but you don't care how far away it actually is - all you need to know is which is nearest. In that scenario you can dispense with Sqr(). In a situation where you simply want to know the precise distance between any two given points, I perform distance calculations like this (fleshed out a bit, for clarity): Function Distance(Point1X,Point1Y,Point2X,Point2Y) 'calculate the x/y distances dX = Point1X - Point2X dY = Point1Y - Point2Y 'calculate exact distance 'Sqr() always returns an absolute value Return Sqr( (dx^2) + (dy^2) ) End Function ...and a 3D version, if its ever needed: Function Distance(Point1X,Point1Y,Point1Z,Point2X,Point2Y,Point2Z) 'calculate the x/y/z distances dX = Point1X - Point2X dY = Point1Y - Point2Y dZ = Point1Z - Point2Z 'calculate exact distance 'Sqr() always returns an absolute value Return Sqr( (dx^2) + (dy^2) + (dz^2) ) End Function oh, and before everybody jumps in and tells me that dx^2 is slower than dx*dx (even though they do the same job) - the speed difference isn't worth arguing about unless you're doing thousands of calculations per cycle. |
| ||
| Oh, Sorry Amon, I went to bed, and didnt realise Id not explained. As GFK has said there are two ways to look at your question 1) What is the Absolute distance between two points 2) Are two points further apart than two other points Gabriel gave you the equation to find 1), and I asked if you needed the distance, or were just going to compare distances. If you are just going to compare distances then if you look SQR(X1*X1+Y1*Y1) <> Sqr (X2*X2+Y2*Y2)as you can see, from simple algebra the Sqr cancel each other, and so you dont need it. @GFK, Ok so as the CPU and FPU get better and better this little bit of performance gain is nothing, but if I am cheacking the distance between ... err 200 spaceships or the like it does make a differance. Also, if I can drop the min from say 700Mz to 650Mz then its not a wasted effort is it? |
| ||
| . |
| ||
DistanceX = Xloc - XLoc DistanceY = YLoc - YLoc So.... What would you expect DistanceX or DistanceY to be? |
| ||
| I don't know. Lol. |
| ||
| oh, and before everybody jumps in and tells me that dx^2 is slower than dx*dx (even though they do the same job) - the speed difference isn't worth arguing about unless you're doing thousands of calculations per cycle. They absolutely do not do the same job. You can test this with this example: For Local x:Int = 0 To 8 Local y1:Int = x^2 Local y2:Int = x*x Print y1 + " " + y2 Next results in 0 0 1 1 4 4 9 9 15 16 24 25 36 36 48 49 63 64 As you can see, they both give different results, with x^2 being less accurate. So if x*x is not only faster than x^2, but also more accurate, then why wouldn't you use it? |
| ||
| Eh? that's a bug surely? How the hell can 4^2 possibly be 15???? Its blatently wrong! dX^2 and dX*dX *should* be the same. In real world terms its the same calculation expressed differently. |
| ||
| Not a bug. The ^ operator calls a function called bbFloatPow(). It takes floats as parameters and uses floating point math and returns floats. There is no Int version. The 4^2 doesn't return 15, but it returns something like 15.99999 and since I am storing it into an Int in my example, it gets truncated to 15. There are more accurate ways to calculate ^, even with floats, but it seems Mark has chosen speed over accuracy, which in my opinion is stupid since even with the faster implementation, X*X is still considerably faster than X^2. |
   |