Game Engineering II Assignment 5

Tony discussed cameras, platform-independent shaders, and physical game objects in the last class. Those seem easy to implement, but every single one is troublesome.
The first thing I did was modify the sRigidBody because it is one of the requisites of moveable cameras and physical objects. The original sRigidBody can move but lacks the fundamental physical simulation. I added forces, drag, and mass, making it possible to handle simple movement by applying force and stopping gradually. 

The second thing I did was create a camera with sRigidBody. Implementing it was straightforward at first, and testing went smoothly until my classmate, Yuri, told me his camera couldn't render anything due to the m_nearPlane for some reason. The same issue happens on my game after setting the same value as the assignment describes. I never figured out why; I just set m_nearPlane a little bigger to make things work.

The third thing I did was change shaders to platform-independent shaders. The process is tedious, spanning macros to replace every difference between OpenGL and D3D and debugging based on (mostly) useless error reports.

The last thing I did was create a GameObject class and subclass called PhysicalGameObject. Because not every game object needs physics simulation, we should omit sRigidBody in the base GameObject class. To do that, I separated the position and rotation from sRigidBody. I added scale to make a struct called sTransform, which makes it possible to represent transform without sRigidBody. The cGameObject class has a sEffectMeshPair array and cMatrix_transformation to store the predicted transform matrix. Putting the predicted transform matrix inside the class is not the best way, but I can't think of a better place to put it. The cPhysicalGameObject has a sRigidBody in it.

I store a cGameObject pointer list in the buffer, which is the only thing added. So, it will only take 8*n bytes (n is the number of game objects we need). If we include the size of each cGameObject, it will take 128*n bytes.

I tested directly passing the transform into cMatrix_transformation and generating the transform matrix into the draw call. It feels jerky, as expected. We only update the physics object unrapidly, which means the render speed will outrange the update speed. So, we pass a tick into the GetPredictedTransformMatrix function and predict the object's movement based on every render frame's tick. 

Click here to download the game.

How to control:
WASD to move the object1. QE to scale the object1,
Left Right Arrow Key to rotate camera. Up Down Arrow Key to move camera back and forward.
Enter to slow down the time.