I'm making an RPG with a type of battle system that has the character surrounded by a circle showing their attack radius. How can I effectively check to see if another sprite is inside the circle?

Basic pyth math...

if( pow(c_x-test_x,2) + pow(c_y-test_y,2) < pow(radius,2) )
{
//inside
} else {
//not inside
}

You don't actually need to use pow() - just multiply them with them selves, this was faster to write though

[edit] Yeah I'm sleepy.

Argh! He asked how to do this effectively .

You shouldn't use pow for integer powers, especially for the second power which is just one *. Well, the compiler could optimise it to * anyway, I guess... But that would be too much to count on.

[EDIT] Hm, did you edit, or is it my inability to read an entire post? Sorry either way .

You can do it pretty effectively with an octagon:

if ((abs(x1-x2) < d1)&&(abs(y1-y2) < d1)&&(abs(x1-x2)+abs(y1-y2) < d2)
return true;

Just tweak the values of d1 and d2, and you can make fast, effective, almost-circular collision detection.

Hm, that can actually be slower on new hardware, because of the inherent branching in abs. Four "if"s can be worse than three multiplications if branch prediction fails. Well, two multiplications, because you can store the attack radius squared as it's (I think) constant.:'(

const int dx = c1_x - c2_x;
const int dy = c1_y - c2_y;
const int dist = c1_radius + c2_radius;

if(dx * dx + dy * dy < dist * dist)
  .. We have a collision! ..

Circle collisions are the fastest of the collision detection schemes. Don't use octagons.
_{* fixed a typo having to do with squaring the radius(plural sp?) before adding them.}

so c1_x would be for circle 1 and c2_x is for circle two?

I understand... sorta.
What if you want to do a collision veetween a circle and a rectangle?
would you just test the circle against the square?

It's not really a "collision" test. More like a "overlap" test. But anyway...

Uhm, yeah. That's pretty much what you do. Only i have no idea how to do it
You probably check against the closest point of the square or test all lines. Dunno.

It's all the game designers fault. I'm gonna go curse him out now then continue trying to figure it out.:'(

Really? Because abs can be written without any branches at all (provided your system has a CMP instruction)...

Output

abs(-31)    31
myabs(-31)  31
abs(-3.1)   3.1
myabs(-3.1) 3.1

Whether or not that is more efficient is yet to be determined, though...

CMP usually doesn't work that way. It doesn't give you a 0 or 1 to store in a register and multiply by, it just sets some flags in a special flags register - which usually can't be the source/target of any computation. The conventional way to use the flags register is conditional jumps, aka branches.

But I admit, on modern architectures you can do it without branches in a multitude of ways. On newer x86, one way that immediately comes to mind is CMOV (however, CMOV might internally behave like a branch, with prediction, prediction misses and all). And for floating point, there is always FABS which is there from way back to the times of 8087 I think.

So, my bad. I didn't think it through properly (like the majority of my posts lately... something's wrong with me).

Anyway, there is no reason to sacrifice accuracy for an improbable speed-up (I don't think even FABS is faster than FMUL, but I might be wrong again), at least not until it becomes a bottleneck.

This is understood; although, it really depends on the system in question. The point was that there are other ways to calculate abs that doesn't require branching, and therefore cannot suffer from branch prediction problems.

*cough*
Floats, as far as IEEE-whatever non-two's-compliment, as PCs are, can also be abs'd by simply clearing the top bit (AFAIK).

Depends. Octagons; no. But a bounding box before the actual circle may prove faster, especially since most box tests fail (so branch misprediction is not THAT big of a deal). I'd say give it a try:

Now go and benchmark this thing, once with box test enabled and once without. See which one is faster with data that resembles what you expect.

Collision detection is the hardest thing I've done (using math) in programming to date. I don't know how to check collision with a circle, and all the code on this site is just a jumble of variables and numbers! When asked how to collide a circle with a rectangle the answer was to check collision with the closest part of the recatangle, but I don't even know how to find that! I'm fairly good at math, but I haven't had the opportunity to learn any of this stuff yet. I'M IGNORANT!!!!! Is there any website out there that goes over this kind of math in a simple, easy to understand way?

www.google.com

I'd recommend buying a math textbook that is just past the last level you finished and reading.

Then repeat the operation (with higher-level textbooks) until you can fully understand what we're all talking about.

bool spheretest(const SPHERE& a, const SPHERE& b) {
  return sqr(a.x - b.x) + sqr(a.y - b.x) < sqr(a.r + b.r);
}

Don't use sqr() (as Dustin already pointed out above).

bool spheretest(const SPHERE& a, const SPHERE& b)
{
  return (a.x - b.x) * (a.x - b.x) + (a.y - b.x) * (a.y - b.x) < (a.r + b.r) * (a.r + b.r);
}

Buy? A textbook? Those things are like, $40-60! I don't have that kind of money! I don't have any kind of money! I've even lost all my Monopoly money!

As for using google, I'm not even sure what this kind of math is called! Is it geometry or trigonometry? Or some wierd kind of quasipsychometry? Yes, I invented a word! Look, a whole post without a single period!

As programmer, you have the hardest job. Therefore, you should design the game to make it easier on yourself.

Fixed it for you. Tobias' example is perfectly fine.

Heh yea, noticed that afterwards... thanks (sorry Tobias!)

Beginners, look for information on the Pythagoran theorem. 

In a right triangle (one with a 90 degree angle),
side lengths a, b, and c
(where c is the long side called the hypotenuse)

a^2 + b^2= c^2

1
|\
| \
|  \
|   \
|   c\
|a    \
|      \
|___b___\2

So if you can figure out the lengths of a and b, you know c.


This is actually the central concept in circular collision detection.
The distance from point 1 to point 2 is:

the square root of (x distance squared + y distance squared):
sqrt(              (2.x- 1.x)^2        + (2.x- 1.x)^2        )

According to wikipedia, the Pythagorean Theorem is euclidean geometry. In practice, I think I learned it in algebra class, though it was more important in trig class.

There's lots of free resources on the web, but finding ones that are actually understandable, particularly for your level of knowledge, may take quite a bit of work. I generally have the best results with programmer oriented sites and wikipedia. Things that come up when I search for "tutorial" are also often useful. A brief googling for online math textbook turned up a site with free PDFs of math textbooks (http://www.math.gatech.edu/~cain/textbooks/onlinebooks.html), but none looked appropriate for you.

Apparently this isn't a good idea, because the processor's caching is separate for ints and floats, and whenever you reinterpret one, it has to wait ages flushing its cache.

For floats, 'fabs' is probably implemented in the FPU and pretty fast. For ints, I tend to do this:

//int y=abs(x);
int y=(x^((signed int)x>>31))+((unsigned int)x>>31);

In two's complement arithmetic, you negate a number by twiddling all the bits and then adding one. In the above code, the XOR will twiddle all the bits if the top bit is set, and then add one if the top bit is set. It does rely on a few implementation-specific aspects of C though.

However, after all that, circle collision detection is probably going to be cheaper!

Okay, I do know the Pythagoran theorem, but I don't know how to use it in programming, just the basic a^2 + b^2 = c^2. I'm actually very good at math, if bored by it, once I've had the chance to learn.

Please cut down on the attitude a little. Just screaming that you're ignorant doesn't make it any likelier someone will really help you. I also recommend you read this.

OK, so if you know the pythagorean theorem, that's a start. You can use it to calculate the shortest distance between two points when given their carthesian coordinates (a.k.a. "x" and "y"): just think of c as the distance, and a and b as the x and y coordinates respectively. Solving for radius, this gives you:
sqrt(x ^ 2 + y ^ 2) = r
...which is, BTW, an equation for a circle about the origin.
Now to use this for sphere <-> sphere collision detection, you'd simply check whether the sum of their radii is larger than the distance between their centers:
sqrt( (x2-x1) ^ 2 + (y2-y1) ^ 2 ) < (r1 + r2)
Since squaring is cheaper than square-rooting, it is a good idea to use take the square of both sides of the equation (which is OK since we're not interested in negative results):
(x2-x1) ^ 2 + (y2-y1) ^ 2 < r1 + r2
Since C doesn't come with a square operator, we need to use a function for that:

sqr(x2-x1) + sqr(y2-y1) < r1 + r2

Only problem is that C doesn't define a sqr() function either, but you can easily do that yourself. I already gave you the code.
The rectangle part is just about using bounding-box checks (basically, a series of 4 simple comparisons) BEFORE the above sphere test, to filter out the obvious non-collisions in a cheap way, avoiding most of the sphere tests (which involve expensive squaring).
In my example, I have used a C++ template for the sqr() function, so that it works with all data types that have a * operator.

Wow, you just made that almost perfectly clear to me. What little I didn't get I'll get when I actually try to use it and have to think it through properly. Thank you Tobias Dammers!

Just a little correction (which was mentioned several times in this thread already, so it must've slipped Tobias this time): If you decide to compare the squares, you have to square the entire thing, which means also the right side of the inequation

(x2-x1) ^ 2 + (y2-y1) ^ 2 < (r1 + r2) ^ 2

I never would have caught that, so thanks to you too!