Engineering Two: Assignment 6

Assignment 6 Download!

So this version of the game, we changed the shaders to be built whilst building assets, as opposed to building them at runtime. This helps performance because players don’t need to wait for the game to build the shaders, we only have to build the shaders once after development (for release), and we can also do any error checking before hand.

So we moved the build process over to the LUA side of things and created a file that holds what assets need to be built, as well as which builder needs to build them. Mine looks like this:

–[[
This file lists every asset to build
]]

return
{
— Generic Assets
— (That just get copied as-is rather than built)
–Handles meshes for the time being
generic =
{
builder = “GenericBuilder.exe”,
assets =
{
“cubeMesh.lua”,
“floorMesh.lua”,
“material.lua”,
},
},
–Shader builders
–Vertex Shaders
vertex =
{
builder = “VertexShaderBuilder.exe”,
assets =
{
“vertexShader.hlsl”,
},
},
–Fragment Shaders
fragment =
{
builder = “FragmentShaderBuilder.exe”,
assets =
{
“fragmentShader.hlsl”,
},
},
}

So once we load it into the C code that checks what needs to be built, it passes the file and its path to the appropriate builder. I split up the fragment and vertex builders so that I can debug each one separately, and I can create specific debug code if necessary. The code is virtually the same between the two, but should a problem arise, I will know it is a problem with one or the other instead of trying to figure out which part of the code is messing up with which assets.

I chose the above code because it’s easy enough to determine which builder to use, as well as the list of assets to build for the given builder. The outer table with
vertex =
or the
fragment =

are not used by the lua reader and are only there for user readability. They are perhaps a bit redundant, as you can tell which builder is being used…right below it. But I imagine if you want to break it up so
cheatCodes =
{
builder = “GenericBuilder.exe”,
assets =
{
“GodMode.cheat”,
},
}

It still uses generic builder, but maybe in a bigger file, it’d be easier to find certain files. That seems like grasping at straws, but it makes sense to me. Also, who would have a cheat file?

We also added some debugging code to make sure that should an error pop up during build time, it points us in the appropriate direction. If there’s a syntax error within the “AssetsToBeBuilt.lua” file, then double clicking in the error window will bring up the file in question and tell us which line is the offending one. Note: This does not actually check for profanity, so offensive lines will still get compiled.

Also, the builder has added debug code to the compiled shaders if they are built in the debug configuration.

Honestly, this assignment was unexpectedly shorter and easier than the others in the class. I spent ~2-3 hours on it, but I wasn’t focused on working on it very well, so it probably worked out to be an hour worth of work. There was a lot of code given by JP, and I was under the impression we’d be writing more lua code, but the files he gave us kind of just took care of it. The only code I had to change on the engine side of things was to adjust how the shaders were being stored (DWORD* instead of CompiledShader). I’m not necessarily saying this was bad, just that I didn’t…learn too much on this one. But I also wasn’t nearly as frustrated with it as other assignments either. :p

Time spent:
2-3 Hours: Adding in the build steps for the shaders
30 Minutes: Writeup

Leave a Reply