This week’s assignment required us to add a camera to our existing. Game can usually have more than one camera, so it was up to the game programmer to submit the camera the graphics should use to render the objects. Another part of the assignment was to add a representation of Game Object. Instead of sending mesh and effects, the game programmer will now submit the game object to graphics for rendering.
Playable EXE Download
Controls: W S A D to move game object
Up Down Left Right to move camera
Ctrl to switch the mesh of game object
I have added my GameObject class to the Graphics project. I felt this might not be the right place to add this class as Game Object is not technically a part of Graphics, but because of the complexity of the project (and I was avoiding creating a new project), I decided it was OK to add it to the Graphics project.
[Edit: We had a discussion about this in class, and it was OK to add it to the Graphics project. Only thing to make sure here is not to add GameObject class to MyGame project.]
Below is my Game Object class. It store a point to mesh and effect (which make ups its renderable component), and a rigidbody for movement.
Since we will be using the extrapolation of game object transform for rendering, I am using the below interface to submit data to graphics
Along with passing the mesh and effect as usual, we will now pass the predicted transform of game object as well. This predicted transform is used in per draw call and now we will store this data as well in our data required to render frame struct.
Below is the data required to be stored for a draw call (mesh effect pointer and transform matrix)
Need for Prediction/Extrapolation
The game update and graphics update run at different speed. The game update happens based on the game frame rate we set (15 in our case), and it is where we actually update our game objects. We have the function UpdateSimulationBasedOnTime() function in our game class for updating the objects. However graphics thread runs at a much faster rate. As the graphics thread is faster and game simulation is slower, we would get a jerky movement of objects without extrapolation.
We will pass the extrapolated transforms of the object to the graphics thread to tell it where to render in the next frame. One thing I initially did wrong here was while passing these extrapolated transforms, I was also updating the actual transform of the object. The jerky movement was gone, but the object was moving way too fast because of two updates happening to object’s position (extrapolation and normal game object update).