Where is the camera rotation being considered?

Also another think I am unsure about is :
dest_x = global.cam_x-x+X[p_num]; // the point to rotate on
dest_y = global.cam_y-y+Y[p_num];
dest_z = global.cam_z-z+Z[p_num];

What are the -x -y -z values?

Hello, I'd suggest learning a bit about matrices. You can accomplish the described things easily and with pretty clean close.

Best regards

Any language that supports structs, or at a push arrays, 'supports' matrices (in that you can easily write a few functions to do matrix manipulation). However, orientation angles for a camera are a reasonable way to go.

Here's my projection code to turn a 3D point and camera orientation into screen coords (C#):


It doesn't handle camera roll, but that's just a manipulation of the screen coordinates at the end.

Oh yeah, my Projection class stores the camera origin in ViewFrom, which is why it's not passed in as an argument.

The only 'vector maths' in that code is assigning ds, which is just the position of the point in question relative to the camera (you can just split it out into three variables if you must, although I really think a struct { int x,y,z} t_vector at the least would be a good idea), and the Rotate function which I forgot to include, sorry about that:



Okay, in basic maths what you do is as follows:

• First, translate the target point into the camera's space: ds=r-ocamera
  
• Then 'unrotate' the target point by the camera's orientation angles. That's what the Rotate function above does, and your code there looks equivalent.
  
• Then do the simple projection, since the point is now in a simple untranformed coordinate system.
  

There is a reason why people are using matrices and vectors to answer your questions. You need to learn how to use them to make games. Its that simple. Because no matter what part of the game you work on, you will need to use them. AI, physics, graphics engines, all use math data structurs. I know it may seem like a pain at first, but these are the 'plain math' you are looking for. The power of matrices is that you can store translation, rotation, scale, shear, reflection, and projection all in 16 floats. Matrix form also allows for the fastest possible way to apply all these things (which any 3d engine needs) to a set of vertices as fast as possible. Again, I reiterate: you need to learn. You may not want to learn them, you may hate math, but in the end your engine will only be a pain in your arse and not fast or functional without them.

A really quick example is using 3d models in your game. Suppose you have a herd of cows (like 15 of them) standing in a field. You could have 15 copies of your cow model with vertices transformed into 3d world coordinates so that each vertex is EXACTLY where it should be in the world. It would work well enough, for that small scenario. But every time a cow moved or turned you would have to recalculate ALL its vertices, which would be a pain and very slow.
Now instead, imagine you had only 1 copy of your cow model, and 15 matrices that described the cows' positions and rotations. Now, you are using MUCH less space. Also, when a cow moves or turns, you only have to modify AT MOST 16 floats, though most often it won't even be that many!

The clincher for using matrices in your case is that the world, view, and projection matrices can all be combined into one matrix that will take a set of vertices (a cow for instance) and put it into your game world, then decide where it is relative to your camera and project it onto your screen with no more work than any of the three would require seperatly.

Finally, graphics cards have hardware (GPU) that will multiply matrices and perform transformations much faster than your CPU. To take advantage of this, you simply pass the card your vertices and a matrices and it will do the transformations very fast, which lets your CPU do other stuff in the meantime (like AI and physics and networking).