Game Engine Engineering Assignment - 4

The goal for this assignment was to get us familiar with the dual thread interface of the engine. The application and the rendering thread have to work in complete harmony. This is achieved by having two buffers. The application thread fills up one buffer with data and then hands it over to the rendering thread. The rendering thread will use the data to render, while application thread is filling up the second buffer with data. Hence both the threads are able to maintain peak utilization

Now one of the task was to create an interface using which a gameplay programmer can change the background clearing color. Given the two thread architecture, we can cache the background color and use it to render the next frame. The method implemented in the graphics library looks like this:

The second part for the assignment was to change our mesh and effect classes to be reference counted. We had some sick macros, from Professor John-Paul's library, which provided us with all the reference counting functions. Using them, I was able to create factory interfaces for cMesh and cEffect for use in our graphics library.

As for the third part of this assignment, we now combine our previous knowledge to create a SubmitMeshWithEffect method so that even meshes could be added in the data to be used by the render thread, hence giving the gameplay programmer, the ability to add meshes through the application.

*Edit I created an interface for the application to communicate with the graphics thread and now the submission of a mesh-effect pair looks something like this in our game code.

We can do some cool stuff with user input if we override the UpdateSimulationBasedOnInput() function. For example, say add another mesh and change the effect on the persistent mesh. Something like this:

Now since there is supposed to be a hard limit in the engine for the number of meshes which can be submitted, I tackled it here by using a pre-processor define like this and hence the structure for the submission data to the render thread is looking something like this.

I still have my doubts in the regard if this would be the ideal way of doing this as depending on MAX_NUM_MESH_AND_EFFECT, the size of sDataRequiredToRenderAframe will just keep on increasing. One way we can tackle this is maybe use an array of sMeshEffectPair pointers instead, hence only reserving memory, whenever it is required. Also by the way, the current sizeof(sDataRequiredToRenderAFrame) = 192, with MAX_NUM_MESH_AND_EFFECT = 2.

Also while I used some structures to make it a bit more convenient for me as a developer, I realize it might not be ideal given the space complexity. This can be seen both in cMesh and cEffect. Their respective byte sizes in an x64 config are 96 and 136, including all the reference counting functionality.

I think there are multiple ways to optimize here. One of the biggest way would be to start putting hard limits on number of vertices and hence removing the whole vector stuff for cMesh. Similarly removing the shaderNames from cEffect. My original thought for adding these dynamic structures were, if a need arises to update a mesh or effect reference, during runtime, without actually creating a new mesh or effect, we can use these structures to create a paradigm to do so and also the fact that we would then be required to store this data in the class.

So keeping in mind all these factors, I would be doing an optimization run with the next assignment.