IsUnitInRange - Theoretical questions to increase efficiency

[Krogoth]

(Multiple questions throughout the post)

I wanna talk about IsUnitInRange function.

Question 1: I should always check if IsUnitInRect before (to prevent a lot of calculations), do I?

Question 2: I should always use squared range constants if calculate distance by geometry (to not use square root), do I?

Question 3: How works UnitInRange event? Does it calculate distances periodically (with rects probably) or something kind of ... smart?

Then I got an idea, that needs to be discussed as well.
In most cases this function uses .../600/700/800/...10N range. There is no real need in more sharpness for most triggered spells.
So, there is an idea to create a function that determines result approximately (but still with high accuracy).
1. Function has a spectre of 100/200/300/.../5000 distances
(50 values)
Let's call this an integer array R[50], R = 100 * i, i = 1..50
2. There is a constant (in that meaning that it is calculated once) real array K[50], K = 100 / R (= 1 / i), i = 1..50
3. There is a boolean array C[2500] that represents an image of 1/4 circle (with some special indexing probably, have not thought about it yet)
4. Condition itself:

return C[R2I(Abs(x - x0) * K[Range]), R2I(Abs(y - y0) * K[Range])]

(C array supposed to have simple 2D indexing here)

Question 4: Is this viable idea?

 

[Krogoth]

Updated (circle -> 1/4 circle)

Is it right place on this forum to discuss it?

 

[deathismyfriend]

u must wait 48 hrs b4 bumping ur post.

1) i wouldnt do that as that would require a lot of rects.

 

[Krogoth]

u must wait 48 hrs b4 bumping ur post.

Ok

1) i wouldnt do that as that would require a lot of rects.

What rects do you mean?
This does not require actual Rects, if you are talking about this, just checks some condition taking UnitX, UnitY

 

[deathismyfriend]

This should also be in wehz not in t&s

It would help if u post the things u are tlking about.

 

[Krogoth]

Ok, I will repost then )

 

[Eleandor]

You're asking for implementation details to which only blizzard knows the answer. Anything in my post is purely speculation based on some experience in the field.

Question 1: No. IsUnitInRange should be faster than IsUnitInRect for several reasons:
- IsUnitInRange is native, and thus uses native arithmetic. IsUnitInRect is going to be implemented in jass (unless you're talking about IsUnitInRegion)
- IsUnitInRange is just a glorified version of "DistanceBetweenPoints", with the main difference being that IsUnitInRange doesn't use square root. It should be faster than checking if a point is in a rect in any case.

Question 2: Yes. Again, note that IsUnitInRange probably doesn't use square root, unless blizzard is the first game developer in the history of the earth to do so.

Question 3: Every game iteration (60 times per second?), the game checks if any events have triggered. In case of UnitInRange, it simply calculates the distance between units. It obviously depends on the event.
<specific unit> in range of <specific unit> - this probably just uses a single IsUnitInRange call, in addition to checking if the unit wasn't already in range 1 iteration ago.
<generic unit> in range of <specific unit> - this probably uses GroupEnumUnitsInRange, with a filter checking if a unit was already in range 1 iteration ago.

Please note that these things depend on the internal mechanics of the engine. No matter what you do, it's very unlikely that you'll be able to beat the performance of a c++ game engine with some clever jass trick.

Question 4: No.

 

[Krogoth]

Thanks for the "speculation". :O
You probably right, there is no need to check rects since it with ~99% probability uses internal check.
To be honest, I forgot that IsUnitInRange function really exist (and wrote ugly code with DistanceBetweenBlablabla (my own function)), I was talking about it just in theory.