Why to use Square Area math instead of Circle Area math?

[afonsolage]

Hello folks,

I was taking a look on some Mu GS sources and I noticed that all of them (At least, the ones who I've looked into), use a Square Math to determine a skill area attack, but WHY?

Take a look on this code sample:

[...]
if (EnableAttack && gObj[tObjNum].X >= x - aDistance && gObj[tObjNum].X <= aDistance + x && gObj[tObjNum].Y >= y - aDistance && gObj[tObjNum].Y <= aDistance + y)
[...]

It check the area of skill as a Square, like on this picture:



But IMO this is wrong, as far we got a skill radios (The attack distance of a skill), we need to use a Circle area. On above picture it shows the difference between Square and Circle area Maths.

Why this is wrong IMO? Because when you use Square Math the skill attacks has a large distance in any diagonal. And the code to use a Circle area is very easy, so i really dont know why to use Square Math. Some one knows why?

Here is the same code, but using a Circle Area:

// (center.X - x)^2 + (center.Y - y)^2 < radius^2
if (EnableAttack && ( ((gObj[tObjNum].X - x)^2) + ((gObj[tObjNum].Y - y)^2) <= (aDistance^2) )

[MentaL]

[navossoc]

Seriously!?

Have you played this game at least once in your life?

Everything work as a square, not as much as minecraft, but you get the point...

Probably they do it because is much faster do a simple comparison than make the difference between two numbers, to elevate them to the square, sum it and then compare.


Not to mention that attack in the shape of X is bizarre, to get good "circle" would need a minimum radius 2.

[afonsolage]

I've played this game much as you can think. Also I know how "square" it looks, but it doesnt justify the use of a Square as a atack area...But I agree with you if the reason is only because a Square is "faster".

Also I didnt understood your last comment

[...]

Not to mention that attack in the shape of X is bizarre, to get good "circle" would need a minimum radius 2.

[rodrigobmg]

Look client assembly to understand why :)

[afonsolage]

Look client assembly to understand why :)

Doesnt need. I think this is just a bad coded section. The entry code uses a function to compare obj1 with obj2, since we already have which objects are on current view port, is better to calculate a area by checking one by one:

int  gObjCalDistance(LPOBJ lpObj1, LPOBJ lpObj2)
{
	if (lpObj1->X == lpObj2->X && lpObj1->Y == lpObj2->Y )
	{
		return 0;
	}

	float tx = lpObj1->X - lpObj2->X;
	float ty = lpObj1->Y - lpObj2->Y;

	return sqrt( (tx*tx)+(ty*ty) );
}

[GM-Andromeda]

it is almost the same actually, but you need to be sure that your region query is larger than your viewport, so, for example, you can hide/show monsters on server side and your client will show them properly. This is, if i am walking and GS process my last coord movement, server needs to update new monsters positions and send them back to me, and if region query is a circle, smaller than my viewport, i will see that all monsters will appear in a circle pattern, but if radius is larger enough, i will see it normally, just like a big squad. So for query, if both circle/squad are big enough, there is no difference.

Now, for attack range, yes, GS should check distance using circle instead of rectangle, because corner points in quad region are out the circle. It is like a legal cheat if you attack in those corners, you will gain some coord range

edit: well, actually the problem here is basically the coordinate system.