Clamping and Seperate Camera Movement
by Robert Rice · in Torque Game Engine · 04/28/2004 (5:23 am) · 12 replies
This question results from further investigation of a previous issue www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=5474 I posted about not being able to turn left (but moving toward the camera instead) after implementing Advanced Camera and Player Movement with a Seperate Camera. Digging deeper, I was able to find exactly where the problem was, which is usually only about half the solution if I'm lucky. At the end of GameConnection::getNextMove(), clamp() is called, which subsequently calls unclamp() just before it returns. One of the values that is "clamped" is the yaw, my variable of concern. There are two macros that clamp/unclamp use, which are defined in the same file right above the two method definitions. The macros are IANG2FANG (called by unclamp) and FANG2IANG (called by clamp). What *seems* to me to be occuring is that FANG2IANG is doing some calculations to 'yaw' and returning a U32 number. That U32 is sent to IANG2FANG in unclamp, which, I assume, is supposed to be a reversal of somesort. However, I am not so sure that these macros are meant to work correctly if the number used is negative (which is the case in the 'Seperate Camera Movement' resource). In any case, this is exactly where the problem is occurring. Does anyone have any enlightenment into how to fix this? Or, more curiously and perhaps less useful, why is this happening to me and appearantly no one else?
Thanks!
Thanks!
#2
04/28/2004 (4:15 pm)
I have a similar problem. I'm using a modified advanced camera that dosen't have a staic offset. It flys around like Zelda OoT's camera, and if you stay still it will come to rest at a specified offset. I get alot of problems when using this resource. I can only turn left, all the other buttons make me go North in relation to the map. Also, if I start to left, adn kepp holding it my player will just keep switching directions, so something isn't working right. I added this to getNextMove(), but it just gives me what I described.while (dirYaw < 0)
dirYaw += M_2PI;
while (dirYaw > M_2PI)
dirYaw -= M_2PI;
curMove.yaw = dirYaw;
#3
First off, I would think the stuff done in clamp/unclamp via IANG2FANG/FANG2IANG wouldn't be the cause of the problem simply due to negative values. The yaw value coming across with moves in first person would have to support negative values because they are relative movements. If they didn't you'd only be able to turn one direction with the mouse in firstPerson.
So just so I can eliminate a few other causes:
- are you guys using HEAD and if so when was the last time you updated it? Its probably been a month since I checked on any changes there, so I'll want to make sure nothing changed there to adversely affect this.
- what compiler/os are you guys using?
- did you guys first expose mCameraObject by going through my resource or Thomas's highlight of it?
I'll double check the resource too, just to make sure all the code is right.
Cory
04/28/2004 (5:04 pm)
Well, I sort of dumbfounded as to why you guys would be having these problems and I'm almost wondering if there some other change/setting affecting it. Obviously I've got this working with several camera of my own and not just the trackCamera attached.First off, I would think the stuff done in clamp/unclamp via IANG2FANG/FANG2IANG wouldn't be the cause of the problem simply due to negative values. The yaw value coming across with moves in first person would have to support negative values because they are relative movements. If they didn't you'd only be able to turn one direction with the mouse in firstPerson.
So just so I can eliminate a few other causes:
- are you guys using HEAD and if so when was the last time you updated it? Its probably been a month since I checked on any changes there, so I'll want to make sure nothing changed there to adversely affect this.
- what compiler/os are you guys using?
- did you guys first expose mCameraObject by going through my resource or Thomas's highlight of it?
I'll double check the resource too, just to make sure all the code is right.
Cory
#4
04/28/2004 (8:55 pm)
I'm using HEAd as of about a month ago. To compile in use a combanation of MSYS, MinGW, and GCC3. And yes I do have the sperate camera object exposed. My camera has a fixed position mode, and even in that I get the wierd controlls. Most of the time, I start walking South(not North) 0 -1.0 0 in relation to the world. Even when I don't have that code in I get wierd controlls. I think it might have something to do with my camera's position and rotation changing every tick. Any help with this would be awsome.
#5
The position and rotation changes shouldn't have any ill effects either. If you look at the video with my resource on using a separate camera move manager, you can see I'm doing that every tick as well.
I would look at stepping through the code when a move is received. If you set a breakpoint inside this block:
BTW Josh - what part of Phoenix are you in? I'm in Ahwatukee. Do you ever attend the IGDA meetings?
04/28/2004 (9:17 pm)
Okay well I'm using VC6, so I can't be any help with it if its a compiler issue related to the macros, but I don't think it is.The position and rotation changes shouldn't have any ill effects either. If you look at the video with my resource on using a separate camera move manager, you can see I'm doing that every tick as well.
I would look at stepping through the code when a move is received. If you set a breakpoint inside this block:
if (!mFirstPerson && mControlObject && mCameraObject &&
(curMove.x || curMove.y)) {You should be able to see what the incoming values of curMove.x and curMove.y are before we translate them into a yaw. Just to be sure those are correct. Actually you could even verify the calculations if needed by looking at the forward vector on the camera to make sure the yaw you're getting is correct.BTW Josh - what part of Phoenix are you in? I'm in Ahwatukee. Do you ever attend the IGDA meetings?
#6
I added this to that block of code:
Every single time these values are 0, I think that might be the problem.
I live in the "Sunnyslope" area of North Phoenix.
04/28/2004 (9:48 pm)
I'm sure its not a compile problem, it compiles with no errors at all.I added this to that block of code:
if (!mFirstPerson && mControlObject && mCameraObject && (curMove.x || curMove.y))
{
Con::errorf("current move.x = %d", curMove.x);
Con::errorf("current move.y = %d", curMove.y);
....
....Every single time these values are 0, I think that might be the problem.
I live in the "Sunnyslope" area of North Phoenix.
#7
or you should check your key bindings to be sure they're assigning the appropriate variables.
Cory
04/28/2004 (10:00 pm)
Well then - I would say you somehow lost this block of code from the beginning of getNextMove(), it should appear somewhere above my addition to the method:curMove.x = MoveManager::mRightAction - MoveManager::mLeftAction; curMove.y = MoveManager::mForwardAction - MoveManager::mBackwardAction; curMove.z = MoveManager::mUpAction - MoveManager::mDownAction;
or you should check your key bindings to be sure they're assigning the appropriate variables.
Cory
#8
04/28/2004 (10:12 pm)
Looking at that again - you shouldn't be able to get into that block of code if both curMove.x && curMove.y == 0 - that's really strange.
#9
04/29/2004 (5:21 am)
OK, guys. I solved my issue last night, and hopefully it will help you as well. I copied two lines of code from Player::updateMove() to GameConnection::getNextMove(). Unfortunately, I am at work and I don't remember exactly what the two lines were. However, somewhere in updateMove() this is an 'if' or 'while' statement that checks if the yaw < -(M_PI), I think. If this evaluates to true then it adds M_2PI to it...something like that. I copied these lines (acutally they both are written on the same physical line, i think) and put them toward the end of Cory's new if block that begins with "if (!mFirstPerson && mControlObject && mCameraObject &&(curMove.x || curMove.y))..." in getNextMove. Voila! I can now turn left. If this doesn't make any sense, I will get the detailed info tonight and post it tomorrow. BTW, I am also compiling in Eclipse with MinWG, etc. Good luck!
#10
@ Robert: I have that code, it doesn't help.
04/30/2004 (9:40 pm)
@Cory: I have all that code. It only echos that when I'm pressing a move button, so curMove.x || curMove.y can't be zero. i'm not sure what the problem is.@ Robert: I have that code, it doesn't help.
while (curMove.yaw < 0)
curMove.yaw += M_2PI;
while (curMove.yaw > M_2PI)
curMove.yaw -= M_2PI;
#11
If the code you are referring to is the code in the box in your last post above, then I don't think that its the code to which I was referring. I played around with the same code you reference here, to no effect. I'll bring in my change tomorrow and post it...I mean it this time!
05/03/2004 (9:33 am)
Josh,If the code you are referring to is the code in the box in your last post above, then I don't think that its the code to which I was referring. I played around with the same code you reference here, to no effect. I'll bring in my change tomorrow and post it...I mean it this time!
#12
05/03/2004 (1:19 pm)
No need to, I fixed it with this(I think its the same code).if (curMove.yaw > M_PI)
curMove.yaw -= M_2PI;
else if (curMove.yaw < -M_PI)
curMove.yaw += M_2PI; 
Torque Owner Robert Rice
Default Studio Name