Angle of slope for mouse movement.

Newbie & Debugging Questions
#1

So, I’m wanting smooth mouse movement, so I’m going to have the player move in directions (0-360).

I click the screen, and I have the slope. Which, is (y2-y1) / (x2-x1)

Now, I need to use trig to get the angle. I’m just stuck right there. Any help? I’m a freshie, so I’m just finishing geometry. So, I know about the whole SohCahToa thing, I’m just not very skilled in its use seeing as we messed with it for like a week out of the whole year.

Thanks.

EDIT/P.S:
I’m also going to need means of moving the players X/Y towards the direction we get from this, so advice on that too is appreciated.

#2 
Math.atan2(mouseY - playerY, mouseX - playerX); //Both are in world coordinates
#3

What theagentd said is correct, but ultimately you don’t really want that angle since it will have to be transformed back into Cartesian coordinates to move your player. Here is how you would achieve what you want. Have three variables, dx, dy, and speed. The variables dx and dy represent the change in the players X and Y coordinate per game loop. In case you are curious, they are named this way with the d because of calculus. Not really important actually, you could name them “changeInX, changeInY” if you prefer. Each game loop, you calculate what dx and dy are:

dx = mouseX - playerX
dy = mouseY - playerY

So now you have the proper direction, but not the proper speed. If you add dx and dy to your players location now they will instantly teleport to the mouse location, which isn’t what you want. To fix this, we scale the values of dx and dy. Think of dx and dy as the sides of a right triangle, and the hypotenuse is the direction you are going to travel. We want this hypotenuse to be the same length no matter which direction the player is heading. We can use the Pythagorean Theorem to figure out that what we want is

dx^2 + dy^2 = speed^2

So what we will do is normalize the d variables: scale the triangle they currently make to have hypotenuse of length one. We do this by calculating the distance using the Pythagorean theorem and then dividing both variables by that distance. Finally, we multiply dx and dy by speed, which will give us the result we want! Here it all is:

double hypotenuse = Math.sqrt(dx*dx + dy*dy);
dx /= hypotenuse;
dy /= hypotenuse;
dx *= speed;
dy *= speed;

// now we have the correct dx and dy, so add those to the players position!

playerX += dx;
playerY += dy;

You can of course do a slight optimization here by dividing speed by hypotenuse and multiplying dx and dy by that. If you are heart set on using trigonometry, then the code would look like this:

double theta = Math.atan2(mouseY - playerY, mouseX - playerX);
dx = speed*Math.cos(theta);
dy = speed*Math.sin(theta);

playerX += dx;
playerY += dy;

This will work just fine as well and basically does the same thing, however, it involves these trig functions which are slow. In a small game it probably won’t matter though. If I were you, I would avoid using math that you haven’t learned about yet since you will not be able to fix any bugs that show up. Hope this helps! ;D

#4

I just wrote very similar code for a game I’m working on. In this code example I have a gun turret in a stationary object which I want to point at my tank. My tank is the playerEntity. The getX and getY are returning the X and Y of THIS object (My gun turret).

Notice that the atan and atan2 return a positive or negative number depending on which quadrant you’re in so you have to adjust for that.


	public void doUpdate(int delta){
		Entity playerEntity = gameLevel.getPlayer();
		float px = playerEntity.getX();
		float py = playerEntity.getY();
		
		float diffX = px - getX();
		float diffY = getY() - py;
		float angle = 0;
		
		// Protect against a divide by zero error
		if(diffY != 0){
			angle = (float) Math.toDegrees(Math.atan(diffX/diffY));
		}

		if(diffX >0 && diffY >0){
			// do nothing
		}
		if(diffX <0 && diffY <0){
			angle = 180 + angle;
		}
		if(diffX >0 && diffY <0){
			// Note, angle is negative so I'm actually subtracting from 180
			angle = 180 + angle;
		}
		if(diffX <0 && diffY >0){
			// Note, angle is negative so I'm actually subtracting from 360
			angle = 360 + angle;
		}

		turretGun.setRotation((float) angle );
	}

At turretGun.setRotation((float) angle ); my angle is the proper angle in degrees. So now my turret’s gun is pointing at my tank.

#5 

	public void doUpdate(int delta){
		Entity playerEntity = gameLevel.getPlayer();
		float px = playerEntity.getX();
		float py = playerEntity.getY();
		
		float diffX = px - getX();
		float diffY = getY() - py;
		float angle = 0;
		
-		// Protect against a divide by zero error
-		if(diffY != 0){
+			angle = (float) Math.atan2(diffY,diffX);
-		}

-		if(diffX >0 && diffY >0){
-			// do nothing
-		}
-		if(diffX <0 && diffY <0){
-			angle = 180 + angle;
-		}
-		if(diffX >0 && diffY <0){
-			// Note, angle is negative so I'm actually subtracting from 180
-			angle = 180 + angle;
-		}
-		if(diffX <0 && diffY >0){
-			// Note, angle is negative so I'm actually subtracting from 360
-			angle = 360 + angle;
-		}

		turretGun.setRotation((float) angle );
	}

FTFY: atan2 takes care of all that.

EDIT: @Riven, looks like your +/- feature is a bit buggy :confused:

#6

Do the sqrt. Do the divide once and multiply by the recip. Forget about atan2 in this instance as you don’t care about the angle. Degrees are for little kids and scripting…radians are your friend.

#7 
vec2 direction = normalize(pos - pos2);

Vectors, just learn those.

#8

What if he wants a cannon aimed at the mouse? atan2 has its uses. xd

#9

[quote]FTFY: atan2 takes care of all that.
[/quote]
Math.toDegrees(Math.atan2(diffX,diffY)) gives positive degrees if the target is to the right of the source and negative degrees if you’re to the left.

But it turns out that the Slick2D rotate command understands that so now the code is:


	public void doUpdate(int delta){
		Entity playerEntity = gameLevel.getPlayer();
		float px = playerEntity.getX();
		float py = playerEntity.getY();
		
		float diffX = px - getX();
		float diffY = getY() - py;

		turretGun.setRotation((float) Math.toDegrees(Math.atan2(diffX,diffY)));
	}
#10

You shouldn’t be using degrees at all here. Everything works with radians.

#11

Didn’t the alarm bells ring when you wrote that? :clue:

#12

Looks fine to me if Y increases downwards.

#13

Yeah, it depends on where your origin is!

Remember, that most GUI software places the origin (0,0) at the top left corner. Slick does this. If you’re using LIBGDX then it’s the bottom left corner.

#14

Never correct for the projection matrix in your vecmath :cranky:

Your cannon will be affected by the same projection matrix, so you’d have to ‘flip’ your angle again if you’d want to aim your cannon in model space. If you do it in screen space, you’re going to create a mess in your code.

Keep all your logic/math in model space!

#15

I understand that. But the rotate method in SLick2D which I’m using requires degrees.


rotate

public void rotate(float angle)

    Add the angle provided to the current rotation. The angle will be normalized to be 0 <= angle < 360. The image will be rotated around its center.

That’s why I’m not using radians.

Also, while it says we’re actually adding an angle to the existing angle it appears to work by simply feeding it the angle we calculated. Although when I was coding the rotation of my tank turret I did have to get the current angle and subtract it from the calculated angle. I’m reviewing my code now to see why it worked one way in one part of my code and another in a different part of my code.

I’m not asking for help, I’m just pointing out that it’s interesting. :wink:

#16

Sure atan2 is handy. But you don’t need it in this example either.

#17

I claim wall hack and aimbot. Why not?

#18

Opps I missed this…quick write up: HERE

#19

Yes, I agree with Riven. Logic / positioning should always be completely and totally separate from rendering. In other words, code the logic in whatever way makes sense to you. Meters, perhaps, where +Y is actually up? Then just do a conversion on these values when you draw. And do that conversion in one common place (a Camera class, perchance?).

Doing this also makes it very easy to zoom in and out, rotate the view, shake the screen, blah blah blah.