After looking at the code, I realized it was probably the fact that the camera smoothing was not fps-independent and the recording was reducing the framerate, so I fixed the camera interpolation code to be shorter, simpler, faster and also fps-independent.
The other day I was revisiting AABB frustum culling for another purpose, and realized that in Ancient Galaxy, I was doing too much work in the frustum culling code.
There is a trick for AABB vs plane testing, in 2D ( as used in the Larrabee rasterizer ), and also in 3D ( used for frustum culling and BSP traversal ), where you take advantage of the axis-alignment of the box to only test a single point of the box to find out if the box is fully in back of the plane. You can also test the opposite point to find out if the box is fully in front of the plane.
Anyways, I saw that my code was always computing both points, to try to distinguish the Outside from Inside and Partial cases, although the code using this function was only checking for Outside or not. So, I made a new function that only does the Outside check.
It's possible doing & using the Inside check can speed up tests b/c once you are fully inside a plane, any children in a hierarchical tree won't have to be re-tested against that plane.
Here is the code for future reference :
bool Shapes::Frustum::Culled( const Shapes::AABox& aBox ) const{ // for each plane of the frustum for ( size_t p = 0; p < Shapes::SidesCount; ++p ) { D3DXVECTOR3 furthestPoint( aBox.Min ); if ( mPlanes[ p ].mNormal.x >= 0.0f ) { furthestPoint.x = aBox.Max.x; } if ( mPlanes[ p ].mNormal.y >= 0.0f ) { furthestPoint.y = aBox.Max.y; } if ( mPlanes[ p ].mNormal.z >= 0.0f ) { furthestPoint.z = aBox.Max.z; } if ( mPlanes[ p ].GetClipStatus( furthestPoint ) == Outside ) { return true; } } return false;}The idea is that if the furthest point on the box in the direction of the normal is behind the plane, then all closer points must be behind the plane as well. Sort of reminds me of the Separating Axis Test.
