Download this week’s game with the simple one-click download below! Once downloaded, unzip, play the executable, enjoy!
Different main mesh: a Christmas cactus for my friend Felicia! Bring on the happy!
Main object: Use arrow keys to move main object left/right/up/down
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
The advantage of the human readable file is that you can read, understand, and debug that file just by reading it, but they do take longer to load and are bigger files. So the idea is to load/store the assets in binary for two reasons: 1) It is more efficient (faster) to load from binary, and 2) it is also more economic (they are smaller) to store the files. So in our regular build and source files, human-readable: since a human needs to be able to interpret and debug them, but in our run-tim binary: because we’ve done all our testing and debugging and now only the computer needs to be able to read them.
There are four pieces of data that each mesh needs: number of indices, the indicies, the vertices, and the number of verticies. I chose to do the number of indicies first (since the binary read in needs to know how many indicies there are so it can jump to the next right place in the data), then the indicies next since they take up less space and are easier to read in a binary format as they are integers. Next I chose to do number of verticies, again because the read in needs to know how many vertices there are so we know the size of the memory, and then the verticies themselves. I could have done number indicies, number verticies, indicies, and then verticies, or a number of different configurations, but regardless of the order I chose, the number of indicies and verticies would always need to be stored before the index and vertex data.
Here is my floor’s binary file with the above listed order:
By default the human readable files are in OpenGL format. Previously I was swapping the UVs and winding orders after loading from the human readable files for D3D. But since I want a quick load at run time this swapping happens during the build for the binary. So the while the human readable files remain the same, the built meshes are different and cannot be swapped across platform. This does however make loading a binary file platform independent. This is how I load the binary data:
Lastly, enough talk! Let’s show the two advantages of the binary files: I made an object with 50436 index count, and 33616 vertex count. Here’s how they compare:
|Human Readable File||Binary|
|Size of file||4.61 MB||886 KB|
|Time to load (seconds)||0.256||0.002234|
Thanks to Zeno who once again helped me with some of the C++ basics I’ve forgotten. It’s been a long time since I did file i/o with c++, and he was very helpful.