This week’s game. One-click download, unzip, play, enjoy! 😀
NancyNewren_ExampleGame 10
What’s New
The only gameplay changes from last week are the colors. Enjoy! 😀
Controls
Main object: Use arrow keys to move
Camera: Left/Right (A/D), Up/down (W/S), Zoom in/out (Q/E)
(When moving the camera things in the world will appear to move opposite. Thus when you move camera left, the world will appear to move right.)
About the Project
This week I moved the creation of mesh assets from hard coded to Lua files… and then played with updating the colors just using the Lua files. It was fun! (At least the last part. Ha ha!) Having the Lua files for the assets is really neat because this opens the possibility to having other tools and programs create the asset files. More than making asset files data driven though, the idea of the raw asset file is to be human readable to make it easy to read, understand, and most importantly debug. In the future I’ll take the human readable file and a binary, but the important thing is when you run into a problem with an asset you want a human readable file that you can quickly and easily read and understand so you can quickly and easily get to debugging.
For instance, this is my floor mesh file:
The order of the indices for the index buffer matters, so it was an easy decision to make the indices an array type table. For the vertices, since the order of the indices maters, that means, that though the vertices can be listed in any order they must be listed in a predictable order, so the vertices table also needed to be an array (as a lua table type dictionary has no predictable order). I decided to group vertex values all together (i.e. a vertex is defined as a position and a color), as I believed that this would make debugging simpler when there are over 100 vertices.
My final decision was to use an array type table for both position and color values as position in math is always ordered (x,y,z), and anyone who knows graphics, when they see 3{4} color values expects (r,g,b,(a)), so I didn’t feel the need to make the color and position tables dictionaries, but it could have been done. I felt though that it was more readable to see the values without extra “x=” and “a=” to clutter the tables.
Additionally
The Lua asset loading took longer than I expected to implement. I thought the hardest part would be switching meshes from pointers to handles (since they now are loading from file like the textures), but turns out it was reading in the Lua files! It’s hard to keep track of the stack! I got stuck being worried I’d lose the stack, so I finally drew myself a picture of all the load and pop points and coded them right the first try! Booyah!
When I started the implementation to Lua file loading, I confused myself quite completely. Zeno helped straighten me out though so I didn’t waste any time. I also have struggled a bit throughout the semester remembering all the c++ syntax as it has been about three years since I last coded in it regularly. While I have been improving all semester, I still got stuck on a couple things, but Zeno was right there with those pieces of c++ syntax I got stuck on right when I needed them.
One More Thing!
Since the Lua files store color as values [0.0f, 1.0f], and the vertex struct expects uint8_t’s, there was a simple conversion of the float * 255. But since computers don’t round, you can end up with numbers like 234.99 and the uint8_t will store 234, not 235. An incredibly simple way around this is, after doing your multiplication, just add 0.5f. Then 234.99 is now 235.49, which truncates to 235. Done and done.
Nancy Games 