Separating Specific Systems from my Graphics Class, so it isn’t doing everything related to Graphics

Download Example Output for OpenGL and Direct3D

Tri_OpenGL.zip

Download ZIP • 177KB

Tri_Direct3D.zip

Download ZIP • 181KB

After looking over the Graphics.d3d.cpp and Graphics.gl.cpp files, we can see that everything related to graphics is stuffed inside this class, this includes the systems to render the shaders and create the meshes that have those said shaders attached to them. Those two systems should be separated, so that they are easier to edit and manage for say a user that would be using our 3D engine in the future. Imagine if we wanted to create multiple meshes, we indeed would want a separate system that specifically manages that portion of the engine, otherwise it wouldn’t be efficient when we go about adding more and more meshes for a game that we would be building. Same goes for the effects that we might see in the game, whether those effects are shaders or textures, they should also be specifically managed by their own system, so the user has more control on how they go about setting them up for the game that they are creating. Whenever we go about building something that a user might use, we should really be thinking about how we go about separating the specific systems that the user might use, so that it is contained in a user-friendly way.

This is the current output of my engine, when we are creating meshes, in this case drawing triangles to the screen, but after separating the mesh and shader rendering systems to their own respected classes, which in my case I named them cMesh and cEffect, this allowed for me to more easily make multiple tringles, to create my wanted visuals. I have done this for both the OpenGL and Direct3D platforms.

Within my Graphics.d3d.cpp and Graphics.gl.cpp files, I ripped out the mesh and shader related code and then put them into their own systems, I made sure that both systems were built in a platform-independent way, so that I wouldn’t need to change the functions names unnecessarily, since the only thing that may be different might be how they bind an effect or draw a mesh to the screen, though in this case there isn’t anything special that needs to be passed into those functions, so they can easily be written with the same name, with the same given parameters and in this case we aren’t passing anything to those functions. If there is ever a case where there is something outrageously different, we could go down the path of adding a macro and specifying whether or not that needs to be included when we are building for a specific platform. I would like to note that it is important that we need to have both cMesh.d3d.cpp and cMesh.gl.cpp files implemented for this to work at all, same goes for the effect system that we built. Here we can see that in both the Graphics.d3d.cpp and Graphics.gl.cpp files, the call for binding a effect and drawing a mesh are identical.

After, looking over both Graphics.d3d.cpp and Graphics.gl.cpp files, we can see that we can actually separate more of the code into their own systems, so that it can reach a point where only one Graphics.cpp file would be necessary, rather than two. Looking at what we are initializing in Graphics we can see that the Views are the main thing needed for Graphics.d3d.cpp and not Graphics.gl.cpp, if we wanted too, we could add a macro that would check which platform we are currently building too, and only have it initialize the Views, if we are building to Direct3D. If we go about making changes in this way, we would only need to support only one Graphics.cpp file, rather than two.