Skip to main content
GameDev.net gamedev.net
🔒 Locked

Camera Movement Issue

Started by Ludovic Apr 1, 2009 at 7:20 PM 2 replies 1.2k views
Original Post
Ludovic
Ludovic
Heyheyhey, I’m trying to make a DirectX demo for my personal use but Ive got stuck on the camera. I’ve followed this tutorial: http://www.toymaker.info/Games/html/camera.html and, although the result rotates (yay), the camera won’t move left, right, up, down or forwards/backwards on its own axis, only the worlds axis. For example, if you rotate 45 degrees to the right and then hit up->forward then you go diagonally forward along the Z axis rather than forward along the x and z axis together (forward movement). The thing is that the source code for the above tutorial works the way I want it to (obviously cus it compiles) but I cant make a working replica of the code in my demo nor copy the bits of the code I want and leave the rest due to the above paragraphs effects. To me the code I have looks like it should work so...I don’t know anymore, any got a clue? =) Link to files: http://siolis.squarespace.com/download/ (Note: The view matrix is processed about 1/2 of the way down the page) It compiles fine and various things happen (the cube translates and rotates, the lights come on and off if you hit O or F etc) if you press 1-9 and hit one of the arrow keys on a querty keyboard. Key 8 and the arrow keys move the cam and key 9 and the arrow keys rotate it. Oh and I’m working in MSVS2008 Express so you will need that to compile. No secrets, copy anything ya like.
Dunge
Dunge
As a general rule, if something compile it don't means that it work the way you intend it to do. That's called a bug. The tutorial seems great, my personal camera code is very similar. He could use "D3DXMatrixLookAtLH" instead of creating the matrix himself though.

I don't have the time to look and debug your application, and I don't think anyone else will. Posting quick relevant section of the faulty code in the thread help for that. Since you don't know where is the problem in your code, you have to debug it. Set the application to be in a way that it don't behave properly, and then add a breakpoint in your camera class and check the values of members variables/final matrix to see if they are all set with correct values.
Ludovic
Ludovic
Quote:
Original post by Dunge
As a general rule, if something compile it don't means that it work the way you intend it to do. That's called a bug. The tutorial seems great, my personal camera code is very similar. He could use "D3DXMatrixLookAtLH" instead of creating the matrix himself though.

I don't have the time to look and debug your application, and I don't think anyone else will. Posting quick relevant section of the faulty code in the thread help for that. Since you don't know where is the problem in your code, you have to debug it. Set the application to be in a way that it don't behave properly, and then add a breakpoint in your camera class and check the values of members variables/final matrix to see if they are all set with correct values.


Really? I didn’t know what a bug is. I mean I know how to program in c++, the DarkGDK and been using MSVS2005 and 8 but I never knew what a bug was till this moment. Thank you so much for telling me. Although that is not the actual issue.

Now that is out of the way: no, the idea is that you can rotate and move forwards and backwards according to cameras axis, not the worlds axis. D3DXMatrixLookAtLH only allows you to move on the world axis due to pram 1 being a D3DXVECTOR3 of 'Camera Position' on the world axis.

I didn’t mean debug it all. It compiles fine (as I said) but doesn’t behave the correct way. I posted the entire program so ppl could download and look at all the bits (hence the reference to where the view matrix was located, vis half way down the main.cpp file).

Try reading an entire post and understanding the sentences before replying. Just a suggestion. ;)

At any rate I've worked out that I was sending copies of the vectors and view matrix to the Render_Frame function rather than the address. Sending the address fixed it, although the orthogonal axis gets distorted by the floating point inaccuracies. I’m going to look into Quaternions if the 'Alternative Methods' bit as described in the tutorial doesn’t work.
Dunge
Dunge
Sorry if my post seems aggressive, I only want to help.

Quote:
Original post by Ludovic
Try reading an entire post and understanding the sentences before replying. Just a suggestion. ;)

I did, this sentence is actually why I said this

Quote:
Original post by Ludovic
The thing is that the source code for the above tutorial works the way I want it to (obviously cus it compiles)

And obviously, you didn't understand cause you re-said it just AFTER saying "I know what a bug is"

Quote:
Original post by Ludovic
It compiles fine (as I said) but doesn’t behave the correct way.

So, what I said was right, it was implementation error and not an algorithm/logic error, and can be fixed easily with debugging.

Anyway, is this case to fix floating point inaccuracies, you should simply normalize every vectors.

[Edited by - Dunge on April 3, 2009 1:44:11 AM]

Topic Locked

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

Sign in to reply to this topic.