Hello everybody,

I am making a 2d car race game and I am a bit stuck in steering the car.

Since now I have a scrolling race track and the car.

You can move the car forward by pressing W and the car will start gaining speed and if you release W the car will slow down till it stops moving. You can move it backward by pressing S and on the same principle like moving forward. The car will move back gaining speed when the button is pressed and will stop slowly when is released.

I have problems implementing the right and left steering.. I think there is involved some trigonometry but I have no ideea how to start.

Here is my update() function:

void update (sf::Time dt)
{
	//score
	output.score += dt.asSeconds();
	output.print_score.setString(to_string((int)output.score));

	//movement of the player
	sf::Vector2f velocity;

	//forwards and backwards
	if(sf::Keyboard::isKeyPressed(sf::Keyboard::W))
		player.speed += 1.5;
	else if(sf::Keyboard::isKeyPressed(sf::Keyboard::S))
		player.speed -= 0.5;
	else if(player.speed < 0)
	{
		do
		player.speed += 0.5;
		while(player.speed == 0);
	}
	else if(player.speed > 0)
	{
		do
		player.speed -= 0.5;
		while(player.speed == 0);
	}

	if(player.speed > 400)
		player.speed = 400;
	if(player.speed < -300)
		player.speed = -300;

	//right and left. Here are my problems..
	if(sf::Keyboard::isKeyPressed(sf::Keyboard::A))
		velocity.x = -player.speed * dt.asSeconds();;
	if(sf::Keyboard::isKeyPressed(sf::Keyboard::D))
		velocity.x = player.speed * dt.asSeconds();
	
	velocity.y = -player.speed * dt.asSeconds();
	player.spr.move(velocity);

	//keeping the car on the road
	if(player.spr.getPosition().x > bg[0].tex.getSize().x - 200 - player.spr.getTexture()->getSize().x)
		player.spr.setPosition(bg[0].tex.getSize().x - 200 - player.spr.getTexture()->getSize().x, player.spr.getPosition().y);
	if(player.spr.getPosition().x < bg[0].tex.getSize().x - 600)
		player.spr.setPosition(bg[0].tex.getSize().x - 600, player.spr.getPosition().y);
	if(player.spr.getPosition().y + player.tex.getSize().y > 600)
		player.spr.setPosition(player.spr.getPosition().x, 600 - player.tex.getSize().y);
}

I dont want ready code. Just some information about steering in 2d.

The game can be downloaded here:https://www.dropbox.com/s/txo3wz5ph2z45n4/game.rar

[attachment=20438:Capture.PNG]

To get accurate steering consider that the car isn't a single unit.

You have to have inertia so that the car continue to move in the direction it was, but then also in the direction that its wheels are taking it.

So a turn is inertia in previous forward + forward in new forward. The turn takes place as the forward momentum is replaced with the new forward momentum, so the graphic should turn with regards to that shift... >.>

So you need a momentum + direction of momentum variable and a direction of wheels and direction of force variable.

If that makes sense to you... this thing that is happening is also what is the cause of that over turn behavior, because the center of the turn is on the center line of the front wheel axle, not the center of the car so when you drive fast and do hard turns there is that fish tail behavior from the back of the car.

There are two simple ways to achieve this.
One, is to have a speed vector, like this:

Speed = [5,0] or Speed = [2, 3.5]

So, to steer it right or left, you'd need to rotate this vector, using something like Speed.Rotate(15º);. It should steer 15º to the left (counter-clockwise) while keeping the vector's length (the speed) intact.
The advantage of this one is that moving your object is as easy as [ Position += Speed ]. But it makes steering a bit trickier, while accelerating/breaking is harder since you need to evaluate how much should go on both sides of the vector.

Also, calculating the length (linear speed) is a costly operation.

As an example, this is an example of a rotation function:

inline static v2 RotateVector(const v2& p_V, const angle& p_Angle) {
    float t_fSin = p_Angle.sin();
    float t_fCos = p_Angle.cos();

    //return v2 (x, y);
    return v2( (p_V.x*t_fCos - p_V.y*t_fSin), (p_V.y*t_fCos + p_V.x*t_fSin) );

}

The second approach is to have a speed value and a direction, vector or angle, like this:

Speed = 30;

Direction = 45º //or ( pi / 4 ) (or even Direction = [0.707, 0.707] )

The advantage of this approach is that rotating is as simple as updating the angle, as in (90º + 15º = 105º). The downside is that you can't simply add 30 (speed) to the position vector.

it should be Position += [Speed * Cos(Direction), Speed * Sin (Direction)].

I particularly prefer the second approach for this kind of movement, while the first one for free movements, with no need for steering.

The second approach is to have a speed value and a direction, vector or angle, like this:

Speed = 30;

Direction = 45º //or ( pi / 4 ) (or even Direction = [0.707, 0.707] )

It may be a good idea to note that this is still a vector, but using the polar notation. ;)

Do you want the car to rotate when turning? It doesn't really need to unless you want the car to actually turn at an angle. You could always keep it forward and just slide it to the left or rigth a bit when steering and moving forward. This will allow you to use FloatRect to do collisions. Otherwise you will need to create a rotated box class for collisions.

That said you can get from the transform the direction this object is facing and then use that to move the object forward, and rotate it a little when you want to turn.

There are two simple ways to achieve this.
One, is to have a speed vector, like this:

Speed = [5,0] or Speed = [2, 3.5]

So, to steer it right or left, you'd need to rotate this vector, using something like Speed.Rotate(15º);. It should steer 15º to the left (counter-clockwise) while keeping the vector's length (the speed) intact.
The advantage of this one is that moving your object is as easy as [ Position += Speed ]. But it makes steering a bit trickier, while accelerating/breaking is harder since you need to evaluate how much should go on both sides of the vector.

Also, calculating the length (linear speed) is a costly operation.

As an example, this is an example of a rotation function:

inline static v2 RotateVector(const v2& p_V, const angle& p_Angle) {
    float t_fSin = p_Angle.sin();
    float t_fCos = p_Angle.cos();

    //return v2 (x, y);
    return v2( (p_V.x*t_fCos - p_V.y*t_fSin), (p_V.y*t_fCos + p_V.x*t_fSin) );

}

The second approach is to have a speed value and a direction, vector or angle, like this:

Speed = 30;

Direction = 45º //or ( pi / 4 ) (or even Direction = [0.707, 0.707] )

The advantage of this approach is that rotating is as simple as updating the angle, as in (90º + 15º = 105º). The downside is that you can't simple add 30 (speed) to the position vector.

it should be Position += [Speed * Cos(Direction), Speed * Sin (Direction)].

I particularly prefer the second approach for this kind of movement, while the first one for free movements, with no need for steering.

It is worth mentioning that what is represented as a vector is velocity. Speed is the scalar absolute value of velocity.

Thank you all. I have changed my mind. Some more cartoonish movement is better suited to the kind of race I want to make. I will try to do my physics homeworks :D

It is worth mentioning that what is represented as a vector is velocity. Speed is the scalar absolute value of velocity.

It is also worth mentioning that speed is a word that doesn't always have to fit its physics definition. If the concept of Velocity is relevant in the game's context, it should certainly be separated; but in case it isn't, it is a perfectly valid choice for its mnemonic value!

It is worth mentioning that what is represented as a vector is velocity. Speed is the scalar absolute value of velocity.

It is also worth mentioning that speed is a word that doesn't always have to fit its physics definition. If the concept of Velocity is relevant in the game's context, it should certainly be separated; but in case it isn't, it is a perfectly valid choice for its mnemonic value!

I politely disagree.

First, because in @Bratie Fanut's game the concept of velocity seems to be important; the player's rate of displacemente is handled differently for the horizontal and the vertical axes - that is, the direction, as well as the magnitude, matters.

Second, because the terms are unambiguous in physics and I believe we should strive for clarity in our code. Another coder (or even @Bratie Fanut himself after a few months) might read this code and have a bit of trouble figuring out why there is a vector named 'Speed'. If the code matches physics, it is so much more clear.