Assignment 3
The write-up should also explain (in your own words) what the point of the assignment was and how you did it
The point? I guess it was to design a platform independent interface. I basically took the two Graphics.cpp files and put them next to each other and played “spot the differences”. I felt like I learned more about OpenGL and DirectX then I did about good design honestly speaking. But going back to the topic of “good design”. Good design in my opinion means to reduce complexity from a point of view, and provide an interface that is simple and easy for a exterior user to use. I saw ahead of time that we were probably going to extract a view port like class. We ended up doing that.
The write-up should contain detail about how you personally completed the assignment:
I created a View port class and used that as my interface for making Graphics platform independent. It also makes sense conceptually with the other classes. You have to have a view port before you can draw shapes or have effects. The viewport as a whole dictates the background color.
Frustrations (Off the topic of the assignment a bit):
My frustrations weren’t with the content of the assignment this time around. My frustrations were actually a result of something I missed in the previous assignment. When you spend 12 hours working on something, and want to be done with it, you miss stuff (not to complain, but the sheer amount of requirements that I need to keep up with is daunting). I have a friggin check list I set up on the side for them. And then when you learn after completing that assignment that one small mistake cost you 16 points, especially when you’re in the middle of working on the next one. You kind of lose focus (Or at least I did).
My previous mistake was that I thought I met the requirement of causing the build to close when the assets weren’t built. All the proper errors would show up saying that assets weren’t built. But then I stopped my testing early because I thought I met the requirement. If continued(by clicking continue) you would eventually get a null error ( I don’t know if this actually counts as a crash… but meh).
My frustrations with this was how ghetto and time consuming it was to test our thing. Clear temp. Run a build. Watch it break. Now build assets. Now run again. Now do that again for 3 other versions. And I would do this frequently at different steps in the assignment to ensure things were running smoothly. But then at the very end I missed the part where the thing breaks, but it’s supposed to break the right way.
On the bright side, from all my frustrations I learned one thing. The error I made in the problem described above was a result of a misunderstanding I had of C++ (which just makes me hate the language more). You can call functions on nullptrs. The function is called, but it passes itself(this) as null. I did not know that. I thought it would throw an error if you ever called a function on a nullptr.
The biggest things I’ve learned from my frustrations and this assignment: I wish we had friggin unit tests to test that the thing is supposed to break the right way (sounds sooo dumb from my perspective still, despite me knowing that the reasoning is that assets are supposed to be built separately). And functions on classes are called with passing “this” no matter what despite the pointer itself being null.
Specific Requirements:
Making Graphics.cpp platform independent was pretty straight forward in my opinion. I found that the concept of a “View port” could be extracted from the code. And so that’s what I did, I created a view port class that would be initialized in initialization. The view port would then handle clearing the back buffer color, as well as swapping the front and back buffer. In clean up I would also clean up the view port and any related parts. You can find my platform independent interfaces for clearing the back buffer below in figure 1.
In figure 2 you can see my interface for initializing an effect. (I actually already did this in the previous assignment). I just require the user to pass the file paths for the vertex and fragment shader.
In figure 3 you can see my interface for initializing geometry. The user has to specify four parameters in my interface: a vertex count, an array of vertices of that count, a index count, and an array of indexes of that count. A pretty simplistic interface in my opinion. Oh, and lastly the indexes had to be passed in under the assumption of using the right hand rule in determining face normals.
The below shows the byte size of my data structures on different platforms
x86 (OpenGL):
cEffect: 16 bytes
cGeometry: 28 bytes
64 bit (DirectX):
cEffect: 12 bytes
cGeometry: 48 bytes
Looking at cEffect above first. Both platforms require a base amount of 12 bytes due to the handles that are stored as member variables. The byte count then goes from 12 bytes to 16 in OpenGL due to the additional storage of a 4 byte program ID. I feel like there is no way to reduce the byte count from this point unless you force a smaller programID ( which could possibly lead to undefined behavior when casting, or a smaller storage for possible programs).
Looking at cGeometry next. On x86 I store three GL IDs that equate to 12 bytes, and an additional structure of 16 bytes that I use to store the vertex count, index count, and pointers to the vertex Data and indexData. On 64 bit: the same structure equates to 24 bytes, I have a handle of 4 bytes and two pointers of 16 bytes total. If I’m being honest, I have no idea where the 4 extra bytes are coming from for 64 bit. Unless I’m somehow doing my math wrong. In general looking at the numbers above for cGeometry however, the only way I can think of to reduce byte size is to store a pointer to my structure instead of the full structure. But that in turn could lead to a cache miss issue.
Credits:
I discussed the assignment with Emma, Bosan, Byreave, and Sumi. That’s it.
Fig 1 : Clear Back Buffer Code
Fig 2 : Initialize Effect
Fig 3: Initialize Geometry