Game Engineer
prj1.jpg

Assignment 08

Assignment 8

Link To Assignment 08

Screen Capture

  1. The write-up should also explain (in your own words) what the point of the assignment was and how you did it

    The core goal of this assignment was to convert the loading of our human readable lua file, to a binary file. We would use a separate geometry builder to convert the human readable file to a binary file, and then directly read a binary file into our game. Reading a binary file into our game versus our human readable file provides two primary advantages: speed and smaller memory size. Our binary file is smaller than our human readable file, means smaller game. Because our file is smaller, it also means loading the file during run time is faster. Having a process in which you convert to human readable, and then binary provides the advantage of both quickly loading data during run-time into the game, as well as providing readability to a file for a developer.

  2. The write-up should contain detail about how you personally completed the assignment:

    From an analysis point of perspective, I attempted to measure the performance gains of loading in a binary file versus a human readable lua file. You can see the results of analysis in Table 1 below, and I performed my tests utilizing the high poly dinosaur model shown above. It is important to note that the two different types of time measurements weren’t recorded in the same project (the binary measurement was made in the engine project, the lua measurement was made in the geometry builder project). And this hopefully should not matter. Two core things were measured together, the loading of the file, and the extracting of data from the loaded file. Both were measured with 64 bit release builds. I also did my testing in a separate branch called “Assignment08TimeTesting“ for reference.

    I’m gonna start off by saying that I am totally unsure if everything I did was correct. Reason I say this is because I did some compare and contrasting with fellow colleagues. Most of everyone I talked to seemed to be getting improved run times of 6 - 8 times faster. I got an improved run-time of 256x times faster. Which seems very different in comparison to everyone else. I double checked the core sections I was measuring and I am sure that I was measuring the correct sections. This leads me to conclude a couple of possibilities that will have to be revisited later: One, I screwed up my time measurements somehow. Two, my lua file really sucked, and that’s just how well my performance gains were. Three, My binary file is really good (which is very unlikely).

    Despite the weird shortcomings, at the end of the day I can for sure say that there was a performance gain from loading a binary file instead of a lua file. A significant of a jump in time performance is observed, so I feel that I can correctly conclude this.

  3. Specific Requirements:

    Looking at Figure 1 and 2 below you can see the non hex and hex contents of the binary file i generated from my custom lua file. The order in which I decided to write data was vertex count => index count => vertex array => index array. Looking at figure 3, you can see the code I used to extract the data from my binary file. I chose this order to make it easier to debug the count values of my file (I can clearly see the count vertex and index count in hex near the start of the file).Vertex count hex is underlined with red, index count is underlined with blue. This order also matters because it dictates the size of the rest of the file contents. I can only read the vertex array if I know how many vertexes there are. I can only read the index array if I know how many indexes there are.

    ORIGINALLY:

    It is important to note that that binary geometry file I build should be platform independent. This means that my binary file should be the same for all platforms. It should not matter if the platform that will use my binary file is running DirectX or OpenGL. Or if the system the geometry is going to be used on is MAC or Windows. Reason being is because at the end of the day what I made was a “geometry file”. It contains only the contents necessary to render geometry. It is up to the user to how they should read that data for simplicity sake.

    UPDATE (10/23/2019):

    After a second pass with some feedback, I change my opinion on the above statement I made. The binary geometry file should be platform dependent, in the sense that each binary should be adapted to D3D or OpenGL winding order. This should be true for a couple of reasons. Firstly, it provides faster load times during engine run-time, the engine doesn’t have to worry about adapting winding order, winding order is adapted during build time in the geometry builder. Secondly, the geometry builder acts as an intermediate for a user to not have to worry about platform dependent code; Lua files have an assumed convention of right handed rule still. I have adapted these new changes in both my code and report.

  4. Credits:

    I discussed the assignment with Mit, Byreave, Bosan, and Sumi.

    Got free dinosaur model from: https://www.turbosquid.com/3d-models/3d-indominus-rex-rig-irex-1182227 . Had to reduce poly count.

Byte Size Time 1 Time 2 Time 3 Time 4 Time 5 Time 6 Time Average
Lua 2664 KB 0.106621 secs 0.103003 secs 0.105022 secs 0.103253 secs 0.104236 secs 0.103864 secs 0.104333 secs
Binary 841 KB 0.000449 secs 0.000432 secs 0.000394 secs 0.000390 secs 0.000396 secs 0.000378 secs 0.0004065 secs
AvgFaster = (LuaTime/BinaryTime) = 256.6622 Times faster
Table 1: 64 bit Lua and Binary comparison tests.

Fig 1 : Non Hex Dump

Fig 2 : Hex Dump

Fig 3 : Code to Extract Binary Data

Instructions:

  • Use left and right arrow keys to move the camera

  • Use up and down arrow keys to move the camera forward and backward

  • Use ‘W’ ‘A’ ‘S’ ‘D’ to move one of the shapes.

  • Use ‘SHIFT’ to change the shape that moves when held down