Game Engineering – II |Assignment – 4
The main objectives of this assignment were to be able to submit mesh and effect data as well as the background color from the Game project instead of having it hard coded inside the graphics project.
Here is the executable MyGame_
This involved figuring out how much and what data needed to be submitted by the user and to be cached when submitted to Graphics.cpp before it was actually rendered on the output screen.
From looking at the code I understood that in order for the graphics engine to run in sync with the game, there needed to be some amount of multi-threading (in this case two threads). This I believe was the ‘bucket’ concept that was explained in class. Here however the buckets themselves weren’t the threads but the structs that carried the data on different threads. More specifically these were the application and the render threads.
From then on it was a simple matter of figuring out what actually needed to be cached for the graphics engine to be able to render the shape information submitted by the game. Moreover, the reason we are caching this data is because when the time comes to actually render the application thread swaps its information with the render thread which is then used for rendering this information. i.e. the caching is required while the threads are waiting for each other.
As for what information the user had to submit, the following image shows exactly that.
Another interesting thing was how button presses were handled in a separate function than the simple UpdateBasedOnInput() function already defined in MyGame.cpp. The difference is between the application itself and the simulation within it. The simulation can pause while the application is still running which is a fairly common concept in game development.
The following GIF shows how live user input manipulates what is rendered in the simulation.
On checking the size of my mesh and effect objects at run-time this was the output.
mesh size = 32 bytes
effect size = 48 bytes
effect size = 20 bytes
mesh size = 20 bytes
As the only extra data we are storing is the integer which stores the reference count for that object, and since we discussed previously how the object mesh and effect are the smallest they can be, is not possible to make the object size any smaller than this.
It could on the other hand be made larger by storing the index data and the vertex data inside the mesh and, storing the shader information inside the effect which again, as we’ve discussed before, is not needed.
The size of each s_dataRequiredToRenderAFrame struct is 656 bytes for me. That means a total of 1312 bytes of memory.