Game Development Community

GetCurrentCamera* with ViewLimit bug

by Eric Robinson · in Torque Game Builder · 04/21/2007 (6:01 pm) · 5 replies

Functions like getCurrentCameraPosition(), getCurrentCameraArea(), etc. retrieve the values of the camera's position before those values are recalculated because of a viewLimit setting.

I found this bug by mounting the camera to the player avatar and then setting viewLimits for the camera. If the player moves beyond the camera's view limits, the camera stops moving across the scene but any calls to the above functions will follow the player in his wayward course off-camera. Essentially: in this scenario, "CurrentCameraPosition" does not return the "current camera position"...

#1
02/23/2010 (12:52 am)
I see this bug too, with getCurrentCameraPosition giving the position before being moved by the view limit code. Is there a way to get the real camera position after being modifed by the view limit code, or do I need to dig into the C++ code and create my own accessor routine?
#2
02/24/2010 (2:12 pm)
I haven't encountered this bug, but looking through the source code, I can see that it does exist.

If you look at t2dSceneWindow::updateCamera, you'll see it updates "mCameraCurrent.mCameraWindow" which is what getCurrentCamera* uses for return values.

If you look at t2dSceneWindow::onRender, you'll see that it calls "calculateCameraView" with mCameraCurrent. If you jump to "t2dSceneWindow::calculateCameraView", you'll see that it manipulates "mCameraCurrent.mSceneMin/Max". If you then return to "onRender", you'll see that it uses "mCameraCurrent.mSceneMin/Max" to set up the real view.

It would be fairly easy to add new functions (getCurrentScenePosition?) that just used the "mCameraCurrent.mSceneMin/Max" values. Unfortunately, they will always be one frame behind because the "onRender" is what recalculates it.

I don't really see why you couldn't move the "calculateCameraView" call into the "updateCamera" function. That would keep the "mCameraCurrent.mSceneMin/Max" values current with any new function calls you made.

Let me know if this helps or if you need more help.

Later!
William
#3
02/24/2010 (2:54 pm)
Thanks for helping detangle this William. Its very appreciated. I have to tried to minimize this situation coming up, but I know it still does, so it would be good to fix.

Ok, so I don't see how "mCameraCurrent.mSceneMin/Max" values get recalculated in t2dSceneWindow::onRender. I see them changed in calculateCameraView, and I see them get used to set up the glOrtho call. I do notsee their values changed in the onRender call unless I am missing something :).

I also see how the mCameraCurrent.mZoomedWindow value, also set at the end of the calculateCameraView, in used to render the Scenegraph in onRender. I also see that the initial mCameraCurrent.mSceneMin/Max values are set from the mZoomedWindow values, I am guessing from last frame? What I wonder is maybe I should calculate the true cameraPosition from the mCameraCurrent.mZoomedWindow values (.point and .extant since they seem to be the corners).

Or do you think I am better off getting the mCameraCurrent.mScene values min/max?

Thanks again for your help.
#4
02/24/2010 (6:08 pm)
In "onRender" about a dozen lines down, it calls "calculateCameraView". That's where the scene min/max get updated.

If I were to guess, I'd say that getting the
"mCameraCurrent.mSceneMin/Max" values is your best option.
#5
05/07/2010 (4:45 pm)
I just wanted to update this thread with the fact that the issue is fixed in TGB 1.75. I am not sure if the getCurrentCameraPosition() call has changed, but my view limits are preserved correctly.

For me the issue was when zoomed in at the edge of my view limit area, then zooming out, and having the camera outside the view limit for a time making my camera movement seem unresponsive for a while until it returned to the legal view limit area. It could be that the code zooming out now correctly check the view limit and keeps it in the correct area.

I haven't checked the code to see what the fix was, but thanks to the dev team for the fix in 1.75. :)