Wat Is Dis I Dont Evan (Range Shenanigans)

[Shrugging Khan]

This.

What is this?

Since when is "range" more of, hmmm, a guidline, than, say, a rigid rule?

PS: Yes, I screwed up the screenshot. You intelligentsies out there will still get the point.

[TechSY730]

Moderately long standing issue,

http://www.arcengames.com/mantisbt/view.php?id=2601

For how much that this kind of bug can mess with balance, I'm surprised it hasn't even been looked at yet. (EDIT: until now)
Though there is the possibility it is just a display issue, like the range circles being wrong, but the range is actually being computed correctly for "can I shoot this without moving first" computations.

[keith.lamothe]

I've looked at the issue a couple of times, just haven't sat down to investigate.  My guess is that it's the approximate range calc showing its approximateness.  At a few specific angles and displacements it can be simply wrong, but it's probably several orders of magnitude faster than sqrt(a^2+b^2)

[TechSY730]

I've looked at the issue a couple of times, just haven't sat down to investigate.

Sorry for my accusatory statements then. 

My guess is that it's the approximate range calc showing its approximateness.  At a few specific angles and displacements it can be simply wrong, but it's probably several orders of magnitude faster than sqrt(a^2+b^2)

Makes sense, but from the looks of the screen shot, this is an edge case where the error reaches an unacceptably high value.
Sadly, I don't really know enough about fast approximations of operations to really help out here.
Though didn't someone find like a "magic number" that for whatever reason when you bitwise and with it (or was bitwise xor?), you get a startlingly close approximation for sqrt?

[Shrugging Khan]

Normally, that probably isn't all that big an issue, but I see two fatal scenarios here:

1. The Ship's miscalculated range is slightly superior to the turret's, whereas normally it would be inferior.
2. The Ship has radar dampening. As in the OP.

[corfe83]

Why not use the exact calculation, but just don't sqrt() either side? I mean compare range squared vs. distance squared? That avoids the sqrt() calculation, for better performance.

[Ranakastrasz]

Why not use the exact calculation, but just don't sqrt() either side? I mean compare range squared vs. distance squared? That avoids the sqrt() calculation, for better performance.

They doubless already do that elsewhere. You do realize that while that does reduce the cost significantly, the cost is still non-zero, and the method they use is obviously even cheaper to run. When you consider that the game can have trouble running as is, You might realize that such an increase in computational cost would slow the game down significantly, unless you lowered the processing requirements, like using lower caps.

[TechSY730]

Is it possible for, if a ship has radar dampening, then for everything firing on it and everything it fires on, a non-approximate range check is used (like the compared squared distance trick)? For all other cases, use the approximation.

[corfe83]

They doubless already do that elsewhere... the method they use is obviously even cheaper to run...

Are you sure they already use it? I only suggested this because of Keith's comment:

At a few specific angles and displacements it can be simply wrong, but it's probably several orders of magnitude faster than sqrt(a^2+b^2)

Keith is a developer of the game, and he's comparing the not-completely-accurate algorithm they use to the sqrt() algorithm. I want to point out we should be comparing it to the squared function instead, since it's also much faster than the sqrt() algorithm.

[Ranakastrasz]

They doubless already do that elsewhere... the method they use is obviously even cheaper to run...

Are you sure they already use it? I only suggested this because of Keith's comment:

At a few specific angles and displacements it can be simply wrong, but it's probably several orders of magnitude faster than sqrt(a^2+b^2)

Keith is a developer of the game, and he's comparing the not-completely-accurate algorithm they use to the sqrt() algorithm. I want to point out we should be comparing it to the squared function instead, since it's also much faster than the sqrt() algorithm.

Well, AFAIK, Anyone who does distance checking, and is competent, will not use the highly expensive method of taking the square root of a distance unless absolutely necessary. Just leaving it in square form is fine for basic comparisons, while squareroot is required for addition and subtraction (I had to do this at one point, but I dont remember where). However, clearly they also are using an even cheaper method than the (dx*dx + dy*dy) ?= range, (always multiply too, since power functions cost ALOT) which I do not know about, but is less accurate than the Pythagorean minus square root method that is usually used.

[corfe83]

Well, AFAIK, Anyone who does distance checking, and is competent, will not use the highly expensive method of taking the square root of a distance unless absolutely necessary

Let's keep the conversation civil, we're all just trying to improve a game we love here .

I think your comment should actually be directed at Keith, the developer of the game, who was the first in this thread to explain that their "approximation" algorithm is an improvement on comparing the results of sqrt().