don't understand angle source in calculations

I'm currently doing a work up of FPS camera math. I know that there is an overwhelming slant to the matrix based approach, but my white whale lately has been the trigonometric math for FPS movement. I was following along in the tutorial: http://www.java-gaming.org/index.php?topic=37448.0 and professed I did not know where the angle "A" came from in the picture from below:

It's just an FOV calculation

Originally Posted by technologist

I'm currently doing a work up of FPS camera math. I know that there is an overwhelming slant to the matrix based approach, but my white whale lately has been the trigonometric math for FPS movement. I was following along in the tutorial: http://www.java-gaming.org/index.php?topic=37448.0 and professed I did not know where the angle "A" came from in the picture from below:

This would be only one angle for the FOV || Field of View. Its not telling you how to set it but giving the a basic pothagorem therum to demonstrate how to calculate the FOV of the players camera. Allowing to let the operation know what it is to draw.

much simpler way

[QUOTE=technologist;1289343]I'm currently doing a work up of FPS camera math. I know that there is an overwhelming slant to the matrix based approach, but my white whale lately has been the trigonometric math for FPS movement. I was following along in the tutorial: http://www.java-gaming.org/index.php?topic=37448.0 and professed I did not know where the angle "A" came from in the picture from below:

This guy is making things way to complicated. There is a much easier way as far as I'm concerned, and always allow elevation to control the verticle movement.

It's degned for a mouse but will work directly the same if it's the center focus of your translation. Current scale can be used as a speed variable without any major adjustments to your systems layout. There is no reason for doing all that fancy stuff when it can be broken down into 4 quadrants since; at all 4 quadrants you will have to evaluate a different measure anyway.

If this doesn't make since draw a circle on the floor representing a compass , break it down into 4 quadrants and further more into 8 subquadrants , and it should make perfect sense then. each one has to be evaluated in order to determin the azmath ( degree of rotation ). this is within 1 moa ( minut of angle ) off less than 1 inch throughout the span of travel

If you are moving on an elevation save a copy of the variables calculated the difference afterwards and add a degenerative effect for uphill vs downhill if you want a more realistic engine. It's not that much extra code and can be evaluated easily. Or just pass the degeneration as a part of currentScale , never realized how portable this was. But you only need pass the Horizontal plane to the function in order to obtain your movement. Vertical plane with horizontal plane would be for a flight simulator or underwater simulator more than a FPS.

and now

Originally Posted by technologist

I'm currently doing a work up of FPS camera math. I know that there is an overwhelming slant to the matrix based approach, but my white whale lately has been the trigonometric math for FPS movement. I was following along in the tutorial: http://www.java-gaming.org/index.php?topic=37448.0 and professed I did not know where the angle "A" came from in the picture from below:

And when it reappears here as a "rotation":

I know better how to build my camera class if I can understand angle A.

I understand why it is there as far as the trig fx, but how is the angle calculated and where does it come from for use in the trig fx?

If you used the function that I posted above now we can get to something a little more complicating. This next part is very partial but you can easily examine it and decipher how to acclimate it to your application needs.

Doing the math inside the function isn't that much more overhead unless you have a few objects running around. MMO's and Online gaming might be faster this way. Single player can be done as such without any real issues with slowing down.

Each step can be broken down further if you like. This however should suffice. It doesn't required multiple calculations on top of the processor. Something to play around with , warning I might have the variables backwards for the camera so if it's rotatingX when it should be rotatingY I apologize in advance. You use atan to get the degrees from the equation , already built in and far easier to use imho.