I guess you mean that the image rotates as you move your mouse sideways? You've already passed the angle in radians to al_draw_rotated_bitmap(), so you get the difference between player2 y and player1 y (to make a vector) to pass as the first argument to atan2(), then do the differences in x to get the second argument. If the returned value (an angle in radians) is "close enough" to the angle you drew the sprite at, it collides. The "close enough" part is to account for the size of the enemy (after all, he's not an infinitely small point).

The distance between the players can be gotten by the good old Pythagorian theorom to see if it's within range or not. If you want to get fancy, you could associate this distance with the "good enough" value by various ways so the closer the enemy was, it'd be easier to hit him, just like you'd expect.

I wish I was articulate.

The guy who answered you on stackoverflow is Matthew, the guy who runs this site.

First of all, I thank you two for the excellent replies. I haven't completely understand it yet, but now I have stronger clues.

Yes, I have the angle when the left mouse button is pressed; as you've said, I draw the rotated bitmap already. I do so here:

For you to understand it more clearly, the angle in this case is a division of mousePos with a constant called mouseSensitivity (Giving the fact that it is a shooter game, I found a way to give to the user the option of choosing between 4 sensitivities.)

The rotation of the bitmap involves a curious solution that I've found:

This "mouse cursor teleportation" solved perfectly an old problem of mine (Maybe there's a clever way to solve this, but if it is, I don't know it yet).

The "mouseSensitivity" is declared together with the mousePos in this way:

LOW_MOUSE_SENSITIVITY is a constant, defined together with these ones:

This "rotation factor" is a solution to a terrible problem. When I've put the mouse.x as an angle argument to draw the rotated bitmap; even with the pivot placed properly, the bitmap didn't rotate completely (360), and then, by testing endlessly, I found that when I divided the mousePos with this value (81.2), the turn was complete (And therefore, mathematically speaking, I could double it's value to get a slower turn, but a still complete turn). I don't know if this all is clear enough, but it's working perfectly.

The thing is, thanks to this odd division, the angle does not go from 0 to 360; instead, it goes from 0.000000 to 6.299999. If I print this angle multiplied by something closer to 28 I can get the 360, but it's irrelevant. Now I've come to my actual problem, and I'm trying to apply this atan2() like this:

And then, inside the loop:

But I receive the following error in terminal:

main.c: In function ‘main’:
main.c:84:2: error: incompatible type for argument 1 of ‘atan2’
In file included from /usr/include/math.h:71:0,
                 from main.c:22:
/usr/include/x86_64-linux-gnu/bits/mathcalls.h:61:1: note: expected ‘double’ but argument is of type ‘double *’
main.c:84:2: error: incompatible type for argument 2 of ‘atan2’
In file included from /usr/include/math.h:71:0,
                 from main.c:22:
/usr/include/x86_64-linux-gnu/bits/mathcalls.h:61:1: note: expected ‘double’ but argument is of type ‘double *’
make: *** [main] Error 1

So, I can't pass an array as an argument of atan2(), and I'm still quite lost. But I'll keep studying... After all, that's what game development is all about, right? Solving terrible problems in the most efficient way .

Thank you very much again!

I wouldn't do that, he is passing dereferences Array Pointers (yeah blame me for this ) to the atan2 function this way....while he SHOULD get the angle between the first two values, this is not formally correct, is it?

You should pass to atan2 only the vectors you want to calculate the angle in respect to the x-axis...in this case you should pass the DIFFERENCE between X and Y coords of the two objects.

Ericson, I encourage you once more to read up some math text about angles, tangents and the like...you basically have discovered the ratio between a circumference and his diameter..namely PI....but you should have known this beforehand (!)

It's worth mentioning that, when dealing with vectors, it's usually best not to resort to explicitly using trigonometric functions (e.g. sin,cos) unless you absolutely must. You will usually get a much cleaner and more performant solution if you stick to vectors.

It's actually extremely rare that you really need trig functions. For example, if you wanted to calculate whether the line between two players is within some angle of a players facing, you could achieve this using unit vectors and dot products. Instead of defining the tolerance (or field of view or spray or whatever you want to call it) in units of theta, you would need to define it in units of cos(theta). Which is fine - in actual fact it usually simplifies things a lot.

To illustrate what I mean, suppose you have two players: p1, p2.

Let D = (p2.position - p1.position)

Let v = D / |D| (unit vector from p1 -> p2)

Let u = p1.facing / |p1.facing| (unit vector of p1's facing)

Now, testing whether p2 falls within the field of view of p1 is the following simple test:

|u.v| > k

k is a value between -1 and 1. This is, in my opinion, much more meaningful than radians or degrees, but if you really must convert, then k = cos(theta).

Note how not once have I needed to use cos or sin explicitly, and I most certainly have not had to touch the filthy atan2!

Using atan2 is usually a sign that you've gone wrong somewhere or, at the very least, there is a much cleaner way of doing it.

Yeah, there was supposed to be an || around the u.v. Thanks for pointing this out pkrcel, I've now fixed it.

Sure, computing k from theta is no big deal, especially considering that it's likely to be a one-off calculation. However, I would still recommend sticking to k on principle, since it will reveal opportunities for simplifications when you start doing more complicated things later on. As soon as you start talking in angles, you will invariably end up going back and forth between the two domains and introducing all sorts of unnecessary complexity along the way.

My point was more about not approaching the problem from an "angles" perspective in the first place. For example, one might be tempted to start with an atan2 to calculate the angle between p1 and p2, and then work from there. This is usually a bad idea. Sure, it does the job, but it is not mathematically elegant.

That said, this was just an example and not that big a deal. It's when you start relying upon trigonometric functions in your core collision code that it can become a really big deal, both in terms of performance and in terms of introducing unnecessary complexity.

Don't get me wrong, I'm a massive fan of trig functions. I use them all over the place, particularly when slapping something together quickly. However, when I'm solving a difficult problem or writing code that matters (either because it has the potential to be complex, or because it needs to be fast) I will make a real effort to avoid trig functions.

It probably depends on the problem. Certainly in 2D, I would argue that in the majority of cases, vector math is more simple.

For example, show me the derivation, using trigonometry, for determining which side of a line-segment a point is on. There is no reason even to enter the "polar domain", but I have seen people do it and get into a horrible tangle.

Quite often you'll find there are tricks to avoid sqrts and divisions. Generally they are more forthcoming than in the equivalent trigonometric solution.

Though I suppose performance is probably not the strongest justification, as one could use lookup tables for either solution.