Blogger Templates

Thursday, September 14, 2017


Graphics (3 of ∞) Cleaning Graphics implementation by adding more meaningful interfaces.

Posted in ,
EAE 6320-001

What now?
I did a lot of prediction in my last post as to where this class is going. In this assignment, I was able to make the graphics platform specific implementation to be platform dependent implementation. This required me to encapsulate a lot of the view specific logic into a separate cView class. Some restrictions like not using any platform-specific macros in my Graphics.cpp allowed me to rethink the architecture at a high level for the encapsulation. Following are my view class methods which were extracted from the Graphics.cpp

Data-driven effect, sprites, and view
The next task I worked on was to give away for the user to specify/modify the vertex and fragment location through a constructor. Earlier, this was hardcoded inside the effect class which prevented the users in defining custom vertex and fragment.

UPDATE : [Image]

Similarly, I also modified the effect class to allow the user to define a meaningful information for the sprite. For my case, to generate a rectangle, I allow the user to specify the center of the rectangle, breadth, and height. This way the user is completely abstracted from the intricate details of the way vertexPoints are handled by OpenGL and Direct3D platforms. To get this working, I had to calculate a starting point for each platform and determine the next point based on the winding order and the user-specified details.

Even the view is now data driven as it allows the developer to specify the color palette he wants to use for rendering the background. While building this interface, I had to segregate the implementation in .d3d and .gl specific files and include them in the build process based on the platform selected.

More rectangles
This part was really simple as all I have to do was to create an extra instance of effect and sprite to render an extra triangle. This involved me to bind and draw hookups in the renderframe on the right order and making necessary cleanups.

Platform independent shaders
I also had to work on building a shader file with my own extension(.sl) that would define for both OpenGL and D3D(.glsl and .hlsl respectively) To get this working, I just moved code from the platform specific files and encapsulating them in a preprocessor macros. Then I had to use the AssetBuildExe to build the .shd files that will be consumed by my cEffect class for the vertex and fragment shader details(.shd). This process made the build simpler by allowing me to build one file in asset building process across both platforms.

Adding rectangles motivated me further, So I was playing with the code to get a patterned version of the boxes.

Taking advantage of encapsulation
As part of above task, I also created a struct for the color palette in addition to view class to help me easily navigate data across methods.

It was really easy for me to encapsulate all the RGB details in a single struct and transfer that group of data using a single variable. This was done as part of the view’s clear method which allows the developer to define what color he/she want to fill the back buffer with.

Overall, this assignment gave me a chance to refresh a lot of the good practices that I learned in my previous class and get crazy with the way I can render rectangles on the screen.