**1**

###
#1
Members - Reputation: **148**

Posted 06 November 2012 - 11:59 AM

Well, I have a bullets vector, that I can get the X an Y position of them. When I create every bullet I create them in the cannon X and Y position, and I also keep the angle that the cannon was in another vector.

The question is... how do I move them in that angle?

I do not want to use gravity or anything like that, just move them in a constant velocity in the direction of the angle I have.

I'm using SFML, and I'm using sf::Shapes for all. So to move the projectiles, I can either use the Move() function, that has X and Y parameters and move the sf::Shape with the value that I put on the parameters, or I can use SetPosition(), that also has X and Y values.

###
#2
Crossbones+ - Reputation: **18511**

Posted 06 November 2012 - 12:16 PM

On a time step of length delta_t, you update the position like this:

new_position.x = old_position.x + velocity.x * delta_t; new_position.y = old_position.y + velocity.y * delta_t;

As usual, I recommend that you use a unit-length vector instead of an angle to begin with, and then you just need to multiply it by the speed.

**Edited by Álvaro, 06 November 2012 - 12:18 PM.**

###
#3
Members - Reputation: **2137**

Posted 06 November 2012 - 12:19 PM

float newX = x + cos(angle) * velocity * deltaTime; float newY = y + sin(angle) * velocity * deltaTime;The angle is expressed in radians, velocity is the speed of the projectiles, and deltaTime is the amount of time that has passed since the last update.

###
#4
Crossbones+ - Reputation: **5205**

Posted 06 November 2012 - 12:31 PM

The general update mechanism of a 2D point with constant velocity towards a given aimed angle looks something like

float newX = x + cos(angle) * velocity * deltaTime; float newY = y + sin(angle) * velocity * deltaTime;The angle is expressed in radians, velocity is the speed of the projectiles, and deltaTime is the amount of time that has passed since the last update.

Though it makes sense to only recalculate the velocity-vector when the input change, since that should be a lot less often then the framerate.

Not that it likely matters much. (and maybe it's animated, and need to change every frame)

Another nitpick: "velocity" is always a vector, and speed is a scalar (the length of the velocity vector), so it would look neater if it said "speed" in the code

**Edited by Olof Hedman, 06 November 2012 - 12:33 PM.**

###
#5
Members - Reputation: **148**

Posted 07 November 2012 - 06:52 AM

One more question. I've seen people saying do avoid moving things with angles, like Alvaro. Why is that so?

###
#6
Crossbones+ - Reputation: **18511**

Posted 07 November 2012 - 07:26 AM

One more question. I've seen people saying do avoid moving things with angles, like Alvaro. Why is that so?

Vectors are a more natural representation, and as a result many operations are easier to do with vectors than with angles.

If you use angles, you'll have to use sine and cosine all the time, precisely to do what you were trying to do in this thread. You are also likely to have to use atan2 to extract an angle from a vector at some point. These operations are very expensive, and at some point you realize that you don't need to go through the angle at all: Just keep a unit-length vector, which is effectively (cos(angle), sin(angle)). Rotating vectors is not too hard, especially if you are familiar with complex numbers, since multiplying by a unit-length complex number is precisely a 2D rotation.

A second reason to avoid angles is that the fact that 0 and 360 degrees are the same angle means that at some point you'll either have non-uniqueness in your representation or a discontinuity somewhere. It also means that figuring out if a direction is between two other directions is tricky, and so is interpolating between two directions.

A third reason is that angles are incredibly messy when you move to 3D. One can still represent a rotation as three angles (see Euler angles), but other representations (quaternions and orthogonal matrices) are much easier to work with (faster, better behavior when interpolating, no gimbal lock).

Getting rid of angles usually results in code that has fewer special cases, is more elegant, is easier to get right and runs faster. The only downside is that you have to educate yourself to think in terms of vectors and matrices instead of the more familiar angle. But it's totally worth it.

###
#11
Members - Reputation: **148**

Posted 10 November 2012 - 01:51 PM

I'm not in college anymore, I'm 21. I'm 100% sure they didn't teach that. =|