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.

MyGameDataSubmission.png

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.

InputTest

On checking the size of my mesh and effect objects at run-time this was the output.

x64 —–

mesh size = 32 bytes

effect size = 48 bytes

x86 —–

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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s