Game Engineering – Building game engine – Part 2

Creating common interface for rendering meshes and binding effects:

The current engine has two different Graphics.cpp files, one each for Direct3D and OpenGL, which perform exactly the same thing. The main functionality of these files are to Initialize the vertices and shading data, Bind shading data and draw the vertices, Render the frame and perform cleanup after rendering is complete. Our assignment is to create a common interface to Initialize, Bind and Cleanup effects and Initialize, Draw and Clean the meshes which is platform independent.

Since all of the code is already present, the first thing we need to do is to identify parts of the original files performing the different functions. Once identified, it is simple to move them to new files and create references to the new files in the old ones. The way I did this is to move one part of the file at a time and commenting the relevant parts in the old file, so that even if there are some errors it would be easy to figure out where things are going wrong. Once it is confirmed that everything is working, I removed the redundant code. I created two header files one for mesh and other for the effect which contain the platform independent function calls and couple of cpp files which contain the actual implementation for specific APIs.

The separation of functions for the effect are a bit more complex since the code contain lots of platform independent and dependent stuff mixed together. Hence, I created another cpp file to hold the platform independent initialization and cleanup process.

Below is the code that binds the effect and draws the mesh which is common in both the Graphics files.

// Bind the shading data

{

s_Effect.Bind();

}

// Draw the geometry

{

s_Mesh.Draw();

}

As an engine programmer we often have to dig deep and write code which directly interfaces with the hardware. But since there are lots of differences between each hardware platform and the vendor APIs that are used to access the hardware, it is easier for us and other programmers to write such interfaces which are platform independent.

Adding an additional triangle to draw, we have to keep in mind the difference in DirectX and OpenGL on the order how they render points, with DirectX using the left hand convention and OpenGL the opposite.

Finally, after moving the mesh and effect representations to their own platform independent interfaces, the graphics classes for each platform now only contains code which renderers the frame which can be moved to its own class to make the graphics class truly platform independent.

 

Visual Studio Graphics Debugger and RenderDoc:

The Visual Studio Graphics Debugger and/or RenderDoc are important pieces of software when writing software related to Graphics. Using these two software we can see the API function calls to DirectX(VS Debugger/RenderDoc) or OpenGL(RenderDoc) at a particular frame in the game. This is useful when there are graphics artefacts in the game and we want to debug where in the render pipeline are they getting introduced. We can look at each API function call and see what is being sent to the graphics card at that particular frame which makes debugging graphics related issues easier.

Following are the screenshots from the VS Graphics Debugger showing the render process for a frame in the game

The game:

The same in RenderDoc (For OpenGL)

The game:

Optional Challenge: As a challenge creating a “house” and a “tree” using triangles. This is done using 7 triangles. The hardest part of this is figuring out the points in the screen coordinate space and adding them in the correct order for the respective renderers.

DirectX:

OpenGL:

Fixing the “Debug x86” bug: My Solution had a strange bug where all configurations were building perfectly except for Debug x86. I first thought that this issue was because of a references issue due to Graphics project not being updated as discussed at this link. But even after fixing the references for the Application project, the issue persisted. So, after doing more investigation, I found out that I added a library reference to “Graphics.lib” in the project settings for my game just for the Debug x86 configuration. The issue got resolved as soon as I removed this reference in the settings and now builds in all the configurations.

You can download the game from the links below

User Inputs

  1. Shift: Plays the game in slow motion when held
  2. Esc: Exits the game.

MyGame_Assignment2_x64 MyGame_Assignment2_x86

Leave a Reply

Your email address will not be published. Required fields are marked *