So this week, we move more functionalities of building assets into lua-controlled.
Here's the effect after adding a new triangle mesh and make it enlisted in the AssetsToBuild lua table:

Next week we're going to work deeper into customizing our various assets builder. To prove that I could step-by-step debug it. Here's a screen shot of debugging MeshBuilder:

Just like BuildAssets.lua, I placed new AssetsToBuild.lua into the same folder of "Scripts". It's intuitive for me to do so because it keeps the same structure as the file directory on disk. These two files should be placed together because they work closely together that BuildAssets method in BuildAssets.lua is coded according to the design of key values and file structure in AssetsToBuild.lua. 

I'll keep the simplest structure of AssetsToBuild.lua as JP proposed. Info of a certain asset is kept under each array table. The array table contains key-value pairs which are convenient for lua program to access. Lua function simply visit array table one by one and call corresponding asset builder.

But obviously, this "raw" structure is not concise and systematic enough. I'll regroup and redesign the structure according to the classification of the assets.

​For BuildAssets project, I deleted input arguments of the custom build step when calling AssetBuilder.exe. The reason is straight forward that AssetBuilder.exe only call lua function with pre-determined asset list, AssetsToBuild.lua. In that, specific asset builders are designated and called. AssetBuilder as a main entrance doesn't need to take in any argument because it works on a predefined routine now.

BuildAssets shall depend on all the asset builders, by the end of this assignment, they are AssetBuilder, GenericBuilder and MeshBuilder projects. The reason is that BuildAssets will call AssetBuilder which will call other builders. All the builders should be ready when BuildAssets is done building.

AssetBuilder should depend on Lua project for sure because it has intensive interaction with lua scripts. Other than that, it also depends on Windows project for utilizing helper functions. It's worth noticing that although AssetBuilder will call GenericBuilder and MeshBuilder, it shouldn't depend on these two because it's a run-time dependency. AssetBuilder doesn't need anything from GenericBuilder or MeshBuilder in order to finish compiling and linking. As BuildAssets depends on all of them. It's already ensuring by the time AssetBuilder is running, GenericBuilder and MeshBuilder will be ready to be called.

Here's a copy of my executable

Update:
According to JP's advice. I made 2 major changes:
1. 2 separate mesh files -> 1 single mesh file. This also brings in the changes of file loading and processing. Here's the new structure of the mesh file:

return
{
-- vertex
    {
        position = 
        {
            0,
            0,
        },
        color =
        {
            1,
            0,
            0,
        },
    },
-- other vertex...
-- index
    {
        0,
        3,
        1,
    },
-- other index
}

So this is about assignment 3. This week we run into some structure design besides copy existing code and modify them. 

We moved from using vertex buffer only to using both vertex and index buffer. Take the square which is made of two triangles as example, using only vertex buffer means we need to write position (2 floats = 8 bytes) and color (4 uint8_t = 4 bytes) for 6 vertex into vertex buffer. This takes 12 * 6 = 72 bytes. While using vertex and index buffer together means need to write position and color for 4 vertex (12 * 4 = 48) into vertex buffer and  6 indices (6 uint32_t = 24), sums up also equals to 72 bytes. Here the difference might be small because we're only drawing two rectangles. When the number of primitives grows, let's say 10 triangles. Vertex only approach takes 12 * 30 = 360 bytes while using both takes (4 * 30 + 12 * 10 = 240 byes. No need to mention situations in real industry where there's hundreds/thousands of primitives. Besides the advantage mentioned above, it's also more intuitive friendly logical to separate data and index of data.

My approach to represent mesh is considering each mesh as a triangle which takes 3 fixed index and 3 user defined vertex. Then everything becomes clear that from the user point of view, we want to do things like "CreateTriangle(vertex0, vertex1, vertex2)". I provided this interface to the user in my code. In our situation, it's not necessary to keep the vertex in mesh struct/class because it's passed into vertex buffer and nothing changes after that. I still keep a vertex[3] member in my mesh class in case of future use. Above that, I keep a static vector containing all mesh instances for render purpose per frame. OpenGL simply use vertex array id to find vertex buffer where we pushed relative info into. But I still keep the vector as the common structure in two implementations.

I was careless enough to miss the fact that direct3d uses a bgra instead of rgba. It takes more than half a hour to find out. Then I added preprocessor macros in order to make vertex struct work as it should for both implementations. As memory management, I make ctor and dtor private. Ctor is called when user calls AddTriangleMesh(v0, v1, v2). Then buffer is allocated by calling create buffer functions which used to be in Graphics implementations. Correspondingly, I have a shutdown function (cleanup might be a better name though...) which calls clear on the vector which then call all the mesh dtor to release buffer. For Direct3D implementation, direct3dDevice is needed in rendering, I pass this in with an initialize interface which takes a void pointer argument then reinterpret cast it back to direct3dDevice pointer in implementation. I hope to learn better ways to do that.

Common interface is always preferred because this normally means saving compiling time because changes could be changed in relatively small area. And this should be done sooner better than later when it grows larger, which means implementations are so different that separating them could be painful and hard to achieve. People need to take more time to get used to the different interface between them. It also helps when doing parallel comparison between different implementations.

My draw function DrawAll (poor name again...) is a static method in mesh class which takes no argument and return boolean to indicate result.

This is where it's called in GL and D3D implementations:

As mentioned above, direct3d doesn't have a "getDevice" method so I use void* pointer to pass device into mesh class. Also, for left handed and right handed difference between the two APIs, the buffer creation is also modified a little bit in order to share the same input.

Here's a copy of the executable part of the solution:

So it comes, my second semester in U of Utah game programming.
I'm taking 3 courses this semester.

Game project 1 is the first part of 3-semester thesis project. We're going to work out a published version of a new title. By the end of this semester, we're going to work out the alpha version of the game. Currently, I'm at the step of coming up with game ideas. We're going to work on teams after we choose a game idea we're all interested in.

Game Engineering 1 is a continuous class from c++ game programming. Based on the engine I worked out last semester, I'm going to add more modules like renderer to the engine. Also, different from last semester when engine is non platform based, it comes to be more specific for windows platform.

Narrative in Game Design is a course concentrating on story telling. I choose this as my selective course. I'm an engineer but I still want to see how we can make a complete and attractive story line. I'm pretty curious about how to make confusing conflicts in games which cause players to think throughout the story line.

More updates will come out as the semester progresses :-)

Well, I finally make that and publish it. I want to use this one as a portfolio and also part as a blog to record my status.

An important thing to do is to finish the experience section, to provide a detailed description to the experiences on resume and also those not on it.

Finally, A Big Welcome!