Assignment 5

The write-up should also explain (in your own words) what the point of the assignment was and how you did it
Working on this, I believe the goal was to get a better understanding of the consequences and design costs of having to use multiple threads in a game engine. You have to manage how to submit data, but you also have to deal with the repercussions of having to predict outcomes between frames. In a strange way I had to restructure my code base even after it seemed it was working due to the lack of need for predictive movement, when such a thing should have been required (more info in last paragraph). Being still fairly confused, I need to spend more time thinking (or seeking answers) on how exactly the two simulation times work in relation to multiple threads.
The write-up should contain detail about how you personally completed the assignment:
In implementing my own custom GameObject and Camera classes, I decided on the interface in which a user would use my objects and cameras to render things to the screen. Fig 1 below represents the most simplified interface that I believed to be best for a game developer to use the current state of the engine.
Specific Requirements:
Looking at table 1 below. Compared to the previous iteration . You can see that the byte count per render object went up by a lot (both builds jumping by 64 bytes). Looking at Fig. 2 you can see that this is due to the addition of a matrix(16 floats, 64 bytes) to the render frame size for each game object that can be rendered. I’m gonna be honest, I’m unsure if adding up the sizes of the geometry, effect, and transformation matrix actually add up to the size of a draw call for a single mesh; In my head it makes sense, but I’m gonna have to get confirmation on this.
As object count scales up, the size of my render frame object and individual game objects quickly scales up. This could lead to memory issues possibly down the line if my render frame gets too large(I could see the OS screaming at me for allocating too large of a single block, I have no idea how large this limitation is).
Prediction is necessary for rendering in out engine because the render frame runs behind the application frame in order to take advantage of multi threading. Looking at figure 4 you can see that before I submit data, I calculate a predicted movement for the object. Some confusion however, before I even implemented predicted movement my objects were already moving smoothly. When I realized I had to add predicted movement I realize I was doing something wrong. This is a guess, but I believe it was due to the fact that I was running my rigid body updates in OnUpdate and not Simulation Update. Submitting data was happening at the same frame rate as calculating input and updating velocity values, which made it seem as though objects were moving smoothly I believe.
I had to purposely cause jerky movement by moving my input and rigidbody updates to Simulation time step instead. This then made it so that when I actually used predicted movement, it seemed to do something and smooth movement. I am fairly confused on how prediction works with the two different time steps we have along with submission. As well as how this flows between the application thread and render thread. It seems very unintuitive to me that the gameplay programmer should care about predictive movement in our engine, or if that is just a result of the bounds of the assignment. I would like confirmation on what parts are “good design for application side” versus “its just to simplify the engine for us”.
Credits:
I discussed the assignment with Bosan, Byreave, Luis, and Emma.