Inconsistant movespeed in CSceneNodeAnimatorCameraFPS

You discovered a bug in the engine, and you are sure that it is not a problem of your code? Just post it in here. Please read the bug posting guidelines first.
Post Reply
drewbacca
Posts: 38
Joined: Tue Jan 30, 2007 6:49 pm

Inconsistant movespeed in CSceneNodeAnimatorCameraFPS

Post by drewbacca »

In CSceneNodeAnimatorCameraFPS.cpp, setting the move speed by the constructor is inconsistent with the setMoveSpeed function.

The setMoveSpeed function is simply "MoveSpeed = speed"

however the constructor initializes MoveSpeed by dividing the supplied speed by 1000, "MoveSpeed(moveSpeed/1000.0f)"


Assuming the internal MoveSpeed variable is supposed to be world units per millisecond while the supplied arguments are world units per second, the setMoveSpeed function also needs to divide by 1000.
drewbacca
Posts: 38
Joined: Tue Jan 30, 2007 6:49 pm

Post by drewbacca »

I found another unrelated bug in the cameraFPS animator. I tried using the setInputReceiverEnabled() function to freeze the camera and allow the user to have cursor control again to click gui elements. However, if setInputReceiverEnabled(false) is called while the mouse is moving, the animators internal variable, CursorPos, is stuck at the last noncenter mouse position. This causes the camera to improperly rotate, since the CursorPos is checked against the center position in the animateNode function.

The fix for this is to simply add:

CursorPos = CenterCursor;

to the reset cursor position code in the CSceneNodeAnimatorCameraFPS::animateNode function

Code: Select all

// reset cursor position
CursorControl->setPosition(0.5f, 0.5f);
CenterCursor = CursorControl->getRelativePosition();
CursorPos = CenterCursor;
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

Since the first problem (which is correctly mentioned in the API docs) introduces unnoticed API changes I'll leave it to bitplane to decide which one will be changed. IMHO the docs for the constructor are unclear, hence it should be changed there. However, that's far more often used, so....
Post Reply