Skip to main content
gamedev.net
🔒 Locked 🎮 Unity

xna simple camera

Started by djsteffey 6 replies 1.9k views
Original Post
djsteffey
djsteffey
im creating a simple camera in c#/xna. i am trying to implement the standard fps WSAD layout with mouse controlling where you look, with A being strafe left and D being strafe right. Below is an excerpt of the code i am looking over 

        public void update(float delta_time)
        {
            KeyboardState kState = Keyboard.GetState();
            MouseState mState = Mouse.GetState();
            Vector3 moveVector = Vector3.Zero;
            if (kState.IsKeyDown(Keys.W))
            {
                moveVector.Z += 3.0f * deltaTime;
            }
            if (kState.IsKeyDown(Keys.S))
            {
                moveVector.Z -= 3.0f * deltaTime;
            }
            if (kState.IsKeyDown(Keys.A))
            {
                moveVector.X += 3.0f * deltaTime;
            }
            if (kState.IsKeyDown(Keys.D))
            {
                moveVector.X -= 3.0f * deltaTime;
            }
        }
this seems contrary to reason as the positive X axis runs to the right and the negative X axis runs to the left. why then do we subtract from the X when moving to the right and add to the X when moving to the left?
remigius
remigius
Whether a positive or negative X results in a move to the left or to the right isn't inherent to XNA and probably shouldn't be anything to worry about. It can for example depend on which way the camera is facing. If the camera faces along the positive Z axis, +X could be a move to the left, but when it faces along the negative Z axis (so exactly opposite facing), +X would then be a move to the right. The same would be true when looking along the pos/neg Y axis.

If you still think it's behaving funny, post some code where you construct the view matrix and in particular also how you calculate the camera target. When using a WSAD control scheme where AD means strafing, you typically want to apply the movement to both the camera position and target, so they stay lined up nicely.
djsteffey
djsteffey 
if (Keyboard.GetState().IsKeyDown(Keys.A))            {                // move camera left                position.X -= delta_time * 30.0f;                Matrix cameraRotation = Matrix.CreateRotationX(MathHelper.ToRadians(pitch)) * Matrix.CreateRotationY(MathHelper.ToRadians(yaw));                Vector3 cameraOriginalTarget = new Vector3(0, 0, 1);                Vector3 cameraRotatedTarget = Vector3.Transform(cameraOriginalTarget, cameraRotation);                Vector3 cameraFinalTarget = position + cameraRotatedTarget;                view_matrix = Matrix.CreateLookAt(position, cameraFinalTarget, Vector3.Up);            }            if (Keyboard.GetState().IsKeyDown(Keys.D))            {                // move camera right                position.X += delta_time * 30.0f;                Matrix cameraRotation = Matrix.CreateRotationX(MathHelper.ToRadians(pitch)) * Matrix.CreateRotationY(MathHelper.ToRadians(yaw));                Vector3 cameraOriginalTarget = new Vector3(0, 0, 1);                Vector3 cameraRotatedTarget = Vector3.Transform(cameraOriginalTarget, cameraRotation);                Vector3 cameraFinalTarget = position + cameraRotatedTarget;                view_matrix = Matrix.CreateLookAt(position, cameraFinalTarget, Vector3.Up);            }

above is the code for the construction of the target and view matrix. i know the +/- of the position doesnt take into account the rotation to make it truely "strafing" because i want to move left and right along the original x axis if that makes sense. and i am pretty sure that i am looking down the + z-axis as well. yaw and pitch are set to 0.0f in the initialization and are never changed (yet)
remigius
remigius

Well, if you want it to conform to this behavior and it's working correctly for you now, I think you can safely stick with it. There isn't anything wrong about the X +/- swap, it just comes down to how you work the coordinate system. I could offer some suggestions on general camera behavior and how to make it 'real strafing', but I'm not sure if you're asking for that, or anything else really [smile]
djsteffey
djsteffey
yeah i can make it work fine even with the +/- swapped on the x-axis, it is just really bugging me why it is like that. I am usually a person that needs to know how or why something is like it is, especially when i dont expect it to be that way.

and i actually dont want 'real strafing'. my camera hovers over the ground looking down and i just want to be able to move over it (like most strategy games when you move your mouse to the edge of the screen)
Zbychs
Zbychs
Be sure to remember that in XNA +Z points "out of the screen" (as opposed to "into the screen" in DirectX), so if you're facing positive Z, then positive X axis runs to the *left* not right. That's probably your problem.
Buckeye
Buckeye
I like to know why my code works logically, also, so I sympathize and am now curious.

There's a difference in your application of signs between your moveVector in your first post (opposite to what you think you should be doing) and the way you move the camera for your view matrix (which would seem to be proper if facing +Z from a position with Z < 1).

What do you use "moveVector" for, and what's your camera's initial position?

Note: if your camera position is at a +Z position > 1, your view matrix will have you looking along -Z (looking from, for instance Z=+5 toward Z=+1), and then your X movements should be reversed.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly. You don't forget how to play when you grow old; you grow old when you forget how to play.
djsteffey
djsteffey
Quote:
Original post by Zbychs
Be sure to remember that in XNA +Z points "out of the screen" (as opposed to "into the screen" in DirectX), so if you're facing positive Z, then positive X axis runs to the *left* not right. That's probably your problem.


bingo...i did not know that. i have always been so use to DX and OGL with +z going into the screen

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.