Move Objects Around

Downloadable

Controls:

Exit: ESC or click X

Pause/Resume: Space (hold)

Hide Mesh: Shift (hold)

Change Effect: Ctrl (hold)

Change Mesh: Enter (hold)

Move Object: Up/Down/Left/Right (hold)

Move Camera: W/A/S/D (hold)

Rotate Camera: Q/E (hold)

Key Point

The key point of assignment 5 is to figure out a way to move things around smoothly. Therefore it is essential to know what a simulation update is.

Representation of A Game Object/Camera

First of all, we need to move things into the GameObject class and Camera class. Here is my GameObject class:

While designing the structure of my GameObject class, I couldn't help but think about what a game object was like in the Unreal engine. In a game, a game object is the smallest unit that we could operate, therefore in my design, mesh, effect, and physics components all become part of the GameObject class. m_IsActive is to indicate whether the object should be rendered in this frame. MyGame used to be responsible for deciding whether the object should be rendered, what mesh should be rendered, and which effect should be used. These are now solved by GameObject class. As you can see, submitting is also done within GameObject, so now MyGame only needs to call:

objects[i].SubmitData(i_elapsedSecondCount_sinceLastSimulationUpdate);

Though GameObject still needs to call a function in the Graphics library:

Graphics::SubmitMeshEffectDrawCallPair(m_Effect, m_Mesh, drawcall);

Camera is similar to GameObject.

Since this time, draw call became an essential component for rendering, the size of sDataRequiredToRenderAFrame also changed. The other reason it should be bigger is that each game object now submits its own data, so I need to keep track of the index. It’s now 308 in GL and 328 in D3D.

Update Game Objects/Cameras

Processing user input is just like what we have done in previous assignments. With sRigidBodyState storing physics data, we can easily speed up or rotate an object. Changing velocity and acceleration was relatively easy, but I spent some time reading cQuaternion when I tried to rotate the camera. As far as I know, quaternion is similar to a simple version of matrix. Therefore it can also represent some kind of transformation. To move along the new forward vector, all I did was multiplying it by the velocity. Another thing we need to pay extra attention to is that updating is only the first step. We also need to predict. This is because though our game/library runs as fast as it can, simulation doesn't, which means it does not update in every loop of the game(in our case, it updates 15 times/s). If we don't predict, sometimes we'll see an object being teleported to another place and abruptly start/stop.

Here are videos of gameplay:

Full Gameplay

FPS Camera

Acceleration

Platform-Independent Shaders

Besides using DeclareConstantBuffer( i_name, i_id ) defined in shaders.inc file, I also found it very useful to redefine/rename the entry point of vertex/fragment shaders, so that they can share the same main function. To get the matrix calculation working, I defined a macro called MutiplyMatrix( matrix1, matrix2 ). Now except for the output section, shaders are fully platform-independent.