Like mentioned in the post from before, I expected to continue to become more familiar with the engine given with this first assignment or two. While the first was getting into the structure of the engine as a whole by adding the Graphics system, now we were tasked with becoming familiar with this specific system by means of abstracting similar functionalities into independent platform specific classes.
I started the assignment slowly, hand writing the appropriate functions that deemed relevant to the two data types (Effect and Sprite) to gain a better understanding of their processes. Though I pushed that aside to focus on the larger task at hand, the abstraction and design, rather than the specific platform implementation. My hunch being that, at a further date and with more graphics experience that the logic would make more sense to me.
As I began to see which parts could be made general and how to construct these platform specific classes, I also gained some experience with the ShaderBuilder and shader data pipeline system at work. After these two objects were properly stripped apart, I got to directly dive into the construction of the triangles which gave me another brush with graphics code. Which I’m sure more chances will come in the following weeks.
In closing, the assignment and content of these lessons were dealing with the design decisions on how to handle multiple platforms in a given codebase. Using a specific example, geometry and shader data, to teach the concepts. My goal was to remove all logic pertinent to the Effect and Sprite types such that any work that deals with manipulating the inner workings of these types were placed in their own classes. I made an effort to ensure that the only properties that reached into these objects were only those necessary like status codes and application IDs.
Debugging on the Direct3D / x64 Platform
Debugging on the OpenGL / x86 Platform
Calling the Interface from Graphics.d3d.cpp
Above is a simple view of my RenderFrame() function, but with details omitted. Here, the information related to Geometry and Visuals (Sprites) are encapsulated into their own objects. With the specific platform specific code abstracted away, the user is just required to call simple Bind() and Draw() calls when drawing the frame on screen.
Remaining D3D vs. GL differences in the Graphics Library
As of this writing, there are two platform dependent Graphics files, one d3d.cpp and the other gl.cpp. They are “supposed” to contain only the specific code or calls related to their platform. This assignment was the first step in abstracting these classes into using a more general interface regardless of which platform it is run on. Sure, currently specific Sprite and Effect classes exist for each platform but in the future that may be abstracted and joined with a more independent Graphics library. In the ideal case, we’ll have a “lightweight” Graphics.cpp file that calls to the correct platform implementation functions.
There are few platform specific code going on in these Graphics files, with most if not all of these few differences only being very specific functionality to GL/D3D APIs. So few that in fact, the following list are very similar and can be included in a future encapsulation:
Like before, you can run these games via the below links. The x64 version uses Direct3D and OpenGL on the other: