General Write-Up

The purpose of this assignment seemed to be primarily on giving us experience with writing platform-agnostic interfaces. This phrasing is, on its face, very nebulous, and left me staring at my computer for a substantial period of time. I could hear the voices.

As discussed in class, one could describe almost anything that a person interacts with as an interface. In that sense, for the purpose of our assignment, the "thing to be interacted with" that we created were functions for the Initialization, Drawing, and Cleaning-up of Mesh data, and the Initialization, Binding, and Cleaning-up of Shader data.

Although the interface created for the Mesh functions was to be platform-independant - that is, the Graphics.[platform].cpp files would both have their platform-specific code replaced by single calls to the same new Interface functions - this still required separation. As discussed in the assignment, almost everything needed to be separated back out. But in the process of doing this, we separated the generic rendering functions of the Graphics files from the more specific vertex-drawing of the Mesh files.

My code which binds the Effect and draws the Mesh in Graphics.gl.cpp. These lines call my Interface, and are identical to those in Graphics.d3d.cpp.

For the Effect representation, far more was able to be split apart. It was encouraged that we do so.

I used the Constant Buffer files as a reference for how to construct my Effect files. I observed that cConstantBuffer.h parents the generic cConstantBuffer.cpp, which refers to platform-specific functions in cConstantBuffer.[d3d/gl].cpp.

After I had first separated my Effects functions and variables out of Graphics.[platform].cpp and ensured that my code still worked, I then set out to refactor Effects from a namespace to a Class. This required me to make a static Effects object at the beginning of the Graphics files. I granted it private functions for the platform-specific calls, and then ran into my first issue: when changing scopes, the pointers for the Vertex and Fragment shaders were lost. They were zeroed out - possibly optimized out? In any case, I needed to then continue emulating cConstantBuffer by creating a struct which would smuggle the data between scopes safely. When that worked, I was done - I'd done the second triangle part much earlier. But I'll cover that next.

The Second Triangle

Because my laptop has an "Intel Iris Xe Graphics" integrated graphics card, I needed to disable this entirely in order to run the Visual Debugging in Visual Studio without it crashing. Very strange, but apparently it's been a previously reported issue with D3D9on12.dll.

Gee Bill! How come your mom lets you render TWO triangles?

Writing the second triangle was straightforward. Tell the program (via the code in BOTH Mesh files) that there will be 2 triangles, and then fill in the now-extended VertexData array with three more points. Not only did I avoid making a boring square, but I ingeniously circumnavigated having to understand the winding order of vertices - by copying the vertices of the original triangle and negating the positive coordinates, I mirrored the triangle across the y=-x line. In doing so, I learned which coordinates were which on the graphs, and was able to then amend the comments with my proper understanding of the vertex winding order.

D3D - ClearRenderTargetView()

This screenshot shows the render target when it is all black (the ClearRenderTargetView() function is highlighted)

D3D - Draw()

This screenshot shows the render target with the mesh (the Draw() function is highlighted). Also, the Pipeline Stages tab is selected, and the mesh is visible as a "wireframe."

OpenGL - glClear()

This screenshot shows the render target when it is all black (the glClear() function is highlighted, and the Texture View tab is selected)

OpenGL - drawArrays() - Texture Viewer

This screenshot shows the render target with the mesh (the glDrawArrays() function is highlighted and the Texture View tab is selected)

OpenGL - drawArrays() - Mesh Viewer

This screenshot shows the mesh's two triangles (the glDrawArrays() function is highlighted, the Mesh Output tab is selected, and the VS output sub-tab is selected)

The Last Few Differences in Graphics.cpp

There are a few things which are platform-dependent that would need to be separated out in order for Graphics.cpp to exist itself, platform-independent.

InitializeViews() - This function is unique to the Direct3D variant of Graphics.
The Back Buffers - Direct3D uses swapChain and OpenGL uses SwapBuffers, but these would have to be moved.
The Color Buffer and the Depth Buffers - Unlike the Frame Constant Buffer, these two buffers would need to be moved.

After such changes, Graphics.cpp could then be a platform-independent file.

Page updated

Google Sites

Report abuse