Hi, I'm trying to make something like a game... where I have a sort of a cannon that shoots projectiles, and this cannon is constantly rotating around itself, and around a point in the center of the screen. And it's 2D


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.

Each bullet needs a velocity vector that looks something like (speed*cos(angle), speed*sin(angle)). You may have to tweak the formula slightly depending on the convention you used to specify the angle.

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.

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.

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

Thank you all. I've had already tried to do with this formula, It doesn't work. But then I tried on another simplified code and it works perfectly, so there is something to do with the rest of my code, not the formula.

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

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.

Hmm, makes sense. Indeed I had some problems with this equality between 0 and 360.

I don't have any idea how it works using vectors for that. Do you have any link for a tutorial? Or can you tell me what to search for?

I don't know of any learning materials for this. But if you tell me what operations you want to perform on your directions, I can tell you how to do them.

Are you familiar with complex-number arithmetic?

Hmm, I don't have any task I need to do right now. I just wanted to learn so I can use in some future project. The game I was making is almost finished, I solved all my problems.

I don't know how old you are or if you are still a student, but the best place to gain some solid foundation about these things is a Linear Algebra course, usually offered in the first year of college.