So this week, we replaced our asset-building-pipeline that used to run on C++ code and changed it over to use LUA. So what do we gain by writing it in LUA instead of just using code? If someone adds a new asset to the game, they don’t need to know how to navigate Visual Studio or know code or anything to add it into a big list of assets that need to be built. Also, LUA is neat because you don’t need to compile the code every time you make a change, which can save a HUGE amount of time if you’re working on a project that takes minutes to build.
So the first thing I did was fix a few problems that I had from last week, namely changing which assets were being built in Debug mode. Apparently I didn’t check that :/ It was a simple macro that I had fixed (and even mentioned in the previous post), but I had only made the change to Release…Whoops… Since I knew what the problem was, it didn’t take too long to fix it. I also removed the solutions from the AssetBuilder projects. I had moved them over when I imported the project, and I forgot to delete all the extra stuff, so now that’s gone.
Adding color to the triangle wasn’t too difficult either. We basically just changed the colors that we pass in to the shaders from white to whatever else. In my case, I chose orange, purple, and green – because they’re awesome. So after you pass in the colors to DirectX, it passes it through a vertex shader which determines where/what color is going to each vertex. This then gets passed to the fragment shader, which blends the colors between the vertices. It is worth noting that the assignment asked for “Your program draws a triangle with three different colors at each vertex,” which is just silly. I don’t imagine you could have three different colors per vertex. 🙂
Adding LUA into my project was a HUGE hassle. And not because importing a project is hard. It seems like 75% of my time is dealing with Visual Studio and trying to finangle it into doing what I want. Apparently, VS is a bit upset that I don’t have my SolutionMacros and DefaultLocations property pages in the EngineeringTwo\breeden_mark\EngineeringTwo\Code folder. I have it one down, in the Game folder. In the property pages, it recognizes the ones in the Game folder. However, if I don’t have those property pages in the Code folder, I can’t import any projects. If I add in the property pages, import the projects, then delete the property pages, there’s no problem…Until I restart VS. Then it says that it can’t load up the projects. I checked the difference in the two files in KDiff to see if the property pages were altered whilst importing the LUA projects, but they remained the same. So I’m unsure of how to fix this (I’m going to try and fix it in the next two days, but if anyone has any suggestions…). I eventually gave up on it so I could move forward.
After LUA was in, the pipeline swap wasn’t too bad. Filling in the code where necessary with LUA calls was pretty easy. A lua_State gets passed in to the C++ function from the lua side of things. Then you make calls to retrieve any parameters you need from the lua_State. This feels a lot like LUA, and a lot less like C++, so you kind of have to go on faith (and have a lot of error checking in place) that the LUA function gave you everything you need. Then you can manipulate that data however you please. If you need to return values to the LUA function, you need to push it back on to the lua_State, along with the type, and then on the LUA side of things, it handles it the same way you did when you received it – with a lot of faith. I was thinking about ways you could improve the interaction between the two languages. You might want to create an interface that handles the checking and everything for you. So instead of saying lua_isstring, you could create a class that holds the lua object and then you could request what you need from the wrapper. Of course, in this assignment we didn’t mess around much with LUA objects, so maybe it’d be easier to pass an object in to C++…but then you’d have to retrieve values based on their name. That might be an interest thing to do…As I’m typing this, I realize that this is probably what Lua++ did, which we used last year.
What took me the most amount of time was setting up the debugging environment. My code was having the hardest time finding the ScriptDir, which I felt was RIGHT THERE. I ended up throwing that macro around a couple places. It turns out that the AssetBuilder required the macros from the Game debugging, like where the AuthoredAssets was. It said it was missing ScriptDir, but it was actually missing a different macro… Took me a long time to figure out exactly what was going on. Bleaugh. Anyways, it’s done.
Notes: Should you use more than one SolutionMacro and DefaultLocations? I feel like unless you have one for each project, you might run in to issues if you want to just run one of them. Or if you need to just build one. Jamie said I had extra property pages, but the ones I saw were for the other projects, so I don’t feel like they are extra so much as specialized. However, I imagine the above issue – not finding ScriptDir or the like, would have not been an issue had they all shared the same pages.
In the Events window, you can see the functions being called to DirectX, so if you choose one that is making a draw call, information will show up in the Details page. It will then show what mesh is being drawn, how it’s being interpreted and moved about, as well as what vertices are being passed to the GPU.
Fixing problems from last time: 30 Minutes
Adding color to the triangle: 30 Minutes
Adding LUA to the project: 1.5 Hours
Swapping the Asset Building Pipeline: 2.5 Hours
WriteUp: 35 Minutes