My views on Assignment 5

• Game screenshots

(Figure 1.0 Game screenshot with two objects)

• A short video demonstrating the following behaviors

1. Objects moving
2. Camera movement
3. Camera zoom in/out
4. Switching Object controller
5. Switching Object geometry

• Screenshot While moving an object

(Figure 1.1 Game screenshot with Object at a different position)

• Object with a different Geometry

(Figure 1.2 Game screenshot with object changing geometry)

• My GameObject representation

(Figure 1.3 The GameObject’s representation)

• To represent physics attributes, I am using the “sRigifBodyState” instance. I decided to keep the variable  publicly accessed so users can directly modify any values as per their game logic requirements inside “MyGame.cpp”.
• I am also storing effect and geometry references to basically make the GameObject representation simple and easy for users to assign/change the effect or geometry data without keeping a separate note of the pairs.
• The string m_Tag variable is basically a tag or an identifier that might be helpful in future assignments.

• This is what users will use to submit Data (GameObjects) to be rendered to Graphics

(Figure 1.4 submitting Objects to graphics. File: Graphics.h)

• Through MyGame, users are required to use the above interface and pass an array(fixed size) of GameObject as parameter.
• In my Graphics I capture the required data by directly copying some and the rest is by calculating.

• Submit/ Switch camera

(Figure 1.5 sending Camera to Graphics. File: Graphics.h)

• Just like GameObjects, users can also submit the camera to render by using this interface from MyGame.
• In case they want to switch the camera during the game, they have to use the exact similar interface and send another camera as parameter.

 

• Size table
  • After adding "sDrawCall" instacne to renderingPair, this is how the size scenario looks like

Platform	Total Data require  to render Single frame	Total Data held by Graphics (twice because we have two objects)
x32	300 Bytes	600 Bytes
x64	328 Bytes	656 Bytes

• Calculation

The "DrawCall" inside renderingPair takes 64 Bytes in both platforms

x32: s_frame(144) + color(4) + (2 * renderingPair(76))

=> 300 * 2(two var) = 600 Bytes

x64: s_frame(144) + color(8) + (2 * renderingPair(88))

=> 328 * 2(two var) = 656 Bytes

• Why extrapolation is necessary
  • Extrapolation is necessary to avoid jerky movement and enable smooth movement on the screen.
  • The Jerky (not so smooth) behavior happens because there might be a tiny(or even bigger) time gap between the physics calculation and the draw call.
  • Also I think we don't want to update physics every single frame.
  • In extrapolations, we take care of this gap by updating the position of the object just before submitting the data to Graphics by using the time passed since the last simulation update.

• It took me around 10.5 hours to finish everything

• The Draw Call to constant buffer part took me the longest to understand it.