Blogger Templates

Wednesday, September 27, 2017


Graphics (5 of ∞) Using lua to build the shaders and modding the settings.ini

Posted in ,
EAE 6320-001

This one is all about replacing our existing c++ code for building the shaders with the lua code and modding the settings.ini to override the default resolution we have been using in the game so far.

Initial Setup
I started this one by making my LuaCompiler generate the output file as luac.exe and the LuaExe project to generate the output file as lua.exe. Once I had that ready, I had to add some new files to the AssetBuildLibrary project which contains a AssetBuildFunctions.lua that is actually meant for generating the shader, license and settings which I will be using. Then I have to configure the item type to be a custom build tool so that I can output the lua file to the $(OutputDir) just incase if the source changes or the target file went missing. I had to configure the custom build tool such that this lua file compiles to lua bytecode for release build and copies the file for debug builds.
Copied version in Debug build

Compiled version in Release build
My understanding of using a compiled version in the release build is for optimization sake. Our file size gets reduced in the byte code form and it’s closer to machine language and I believe it would be faster to process the file in that form. The only disadvantage I can think of after compiling the lua file is losing the readability of that file. As you can see in the screenshot, the data that I can see in a brackets(notepad) is garbage.

Fixing Dependencies
Now we have a situation where the AssetBuildLibrary has to rely on luac.exe for compiling the lua files but the luac.exe is available only after the solution is built. This goes back to my previous post on the way dependencies work. We will have to set the dependency for AssetBuildLibrary to the LuaCompile project. Since the AssetBuildLibrary also make direct calls to the lua function, we would need a reference for the LuaLib project.

Moving to Lua
In the newly added files for the AssetBuildLibrary, we have new methods inside the Functions.cpp that does all lua related operation. This file also has a method BuildAssets which is responsible for building all the assets which was done previously by the AssetBuildExe. For this process, I had to do some filler code inside the Function.cpp where I was able to refer some patterns in the same file for understanding how I can access data from lua state and have the implementation complete. Then I moved whatever I had done to generate the shader inside the entrypoint.cpp to the AssetBuildFunctions.lua. Again, I was able to take some references from the existing implementation on how I can read the fragment, vertex and the vertex layout and mod them as per my requirement. Then I had to replace the existing AssetBuildExe entrypoint.cpp to a new one such that all it does is to call the BuildAssets function from the AssetBuildLibrary project.

Using settings.ini for resolution
Once I had the Lua flow in the right order, I started working on the settings.ini that can allow custom resolution for our game project. To do this, I had to add a settings.ini as part of the UserSettings project which will have the resolution width and the resolution height. Now, I have to setup the custom build tool for this file such that it gets copied to the $(OutputDir) across all configuration and all platforms. Earlier we were using a default resolution for the game project as 512x512 that was directly loaded from the application. Now, the existing logic for getting the desired resolution from the settings.ini will check for the file availability and then process the available width and height. Since our settings.ini is only configured to be copied to the $(OutputDir), this validation will fail. Hence, we will have to do an extra step of adding logic to copy the settings.ini from $(OutputDir) to $(GameInstallDir) using the AssetBuildFunctions.lua.

Following are screenshots of the game at 512x512 and 800x800. For the screenshot purpose, they might not reflect the actual size of the game window but you can see the result has difference in terms of the resolution.
Assignment05 512x512.gif
512 x 512

Assignment05 800x800.gif

After this, the game project would run with the new resolution we have setup in the settings.ini file. I was able to figure out the key I have to use in settings.ini by inspecting the UserSettings.cpp. Now I have settings.ini as part of my $(GameInstallDir) such that the game can rely on the resolution during runtime. This means that even if I delete the settings.ini, the game would load in the default resolution or I have an advantage of playing with the resolution as per my need without modding any of the original code. That is also another reason why I don’t compile the settings.ini, I want the users to be able to easily change the resolution for the game based on the monitor he/she uses to play the game. From my personal experience of building apps and games, I feel it would be a good practise to allow some form of customization by the user. In many cases, the environment we are developing is different from the environment on which it is being run. Giving user some control on the settings allows our game to suit a wider audience. For a game like application, this settings can include anti aliasing, gamma value, level of detail, view of coverage and many more to be customizable by the user.