Hi,

I’ve updated my program code with a snippet that I found on the internet to add trig.strafe features to my glut FPS camera. Amazingly, it worked right away. Unfortunately I didn’t learn much from the update, and I wanted to know how the code added works (see ‘ADDED’):

```
void computePos()
{
std::cout<<"computePos called"<<std::endl;
if (pGv->strafe_left == true || pGv->strafe_right == true)
{
x -= cos(pGv->angle ) * (pGv->deltaMove); //ADDED
z -= sin(pGv->angle ) * (pGv->deltaMove); //ADDED
std::cout<<"strafe positioning"<<std::endl; //ADDED
}
else
{
std::cout<<"normal positioning"<<std::endl;
x+= pGv->deltaMove * lx * 0.1f;
z+= pGv->deltaMove * lz * 0.1f;
}
}
```

I plan on moving onto matrix calculations movements and views, including strafing, but I wanted to see how it was done with basic trig. I know that with matrix formulations, it would be the vector that is the cross product of the front view vector and the up vector: want to finish understanding trig though.

UPDATE/Narrowing of question:

I had to update early: I feel the need to narrow the question down a bit while awaiting an answer:

I noticed the added code had the appearance of being opposite to the directional calculation:

preexistring directional vector calc:

```
lx = sin(pGv->angle);
lz = -cos(pGv->angle);
ly = 0;
```

added strafe code

```
x -= cos(pGv->angle ) * (pGv->deltaMove);
z -= sin(pGv->angle ) * (pGv->deltaMove);
y =0;
```

Is it a fair assessment to make that the opposite-nish of the 2 calculations keep the strafing at right angles to the direction vector?