Update #1
This week, I modified graphics submission data to accomodate static meshes, and researched into terrain generation algorithms and implementation.
​
Static meshes submission:
Previous Work:
In previous work, the game program submits game objects every frame. A game object contains a mesh, an effect, and physics data such as position, velocity, etc.
Since the position of game objects may change due to movement, the graphics program needs to update draw call data every frame to compute the position.
However, static meshes such as terrain and level layouts do not move for most gameplay time. In this case, if we still submits them every frame as game objects, the memory storing and submitting unused data (unchanged game objects, physics data such as position/velocity/etc.) and the time updating draw call will be wasted.The waste can be significant if there are many static meshes, which is a common case for terrain and level layouts.
Improvement:
To improve, I created a struct storing the static data. Then, the graphics program hold a static instance of the struct like sDataRequiredToRenderAFrame.
Then, when rendering a frame, the graphics program will first render the static objects with data stored in the struct. When rendering the static objects, the draw call data does not need to update. Then, the dynamic objects that may move will be rendered, with draw call data updated for each object. This saves processing time.​
I implemented a function to submit the static objects, which will update s_DataStaticObject.
The game program submits the static objects at the start of the game and whenever the static objects need change (chests appearance, level transition, etc.).
The game program does not need to store the static objects as game objects anymore, because their position will never change. When submitting every-frame data to Graphics program, static objects also do not need to be submitted. This saves runtime memory.
​
Overall implementation progress:
Like MeshBuilder, I plan to make the procedural generator a console app inheriting from iBuilder. Since the generation can take long time, it's important to run it during build time.
The program reads the json files of procedural generaiton parameters, then generate data and export the data into mesh files. Then, the MeshBuilder can build it into binary files.
​
Terrain generation research:
After research, I find Fractal Brownian Motion (fBm) can be a good algorithm for terrain generation. fBm is the sum of multiple Perlin noise layers, which keeps the smooth transition but has more details for generated data.
I chose stb_perlin.h as an external library to generate fBm, because it's light-weight as a single header file yet performs efficiently.