This game is a simple sprite animation. Sit back and enjoy the ambiance!
(Simple one-click download. Once downloaded, unzip, play the executable, enjoy!)
About the Project
In this project I encapsulated effect and sprite code into a struct. I chose a struct, but a class would have been identical in code as the only difference between a class and a struct is a struct is public by default and a class is private by default. The purpose of this was to eliminate duplicate code and to ensure any differences in code were intentional.
The process of encapsulation wasn’t exactly straightforward as it was complicated by the fact that I am publishing to essentially two different platforms: one with Direct3D and the other OpenGL. So in addition to creating the typical .h and .cpp files, I also created structName.[platform].cpp files which held the larger portions of code that were dissimilar between the platforms. Thus creating a platform independent interface and two platform specific implementations. In the case of the effect, there was an additional fourth file which handled the platform independent parts of binding, initializing, and cleaning up. The sprite did not require this fourth file as there were not enough similarities between the initializing, drawing, and cleaning up to warrant any platform independent functions.
I utilized Notepad++’s compare plugin a lot in this assignment. It made it vey quick and simple to view the differences along side the similarities. All large differences were moved into platform dependent files while small differences where set out in the same file but with preprocessor macros to turn the code on and off depending on the platform build.
With the effect and sprite code now encapsulated within sEffect and sSprite respectively, the code in Graphics.[platform].cpp to bind and draw is now this:
// Bind the shading data
effect.Bind();
// Draw the geometry
sprite.Draw();
The color and color animation were updated and made smooth by using the equation I mentioned last time:
0.5*sin(time) + 0.5;
The only real differences left between the Graphics.[platform].cpp files that are left involve the view for the d3d, and clearing the image buffer before binding and drawing. This could be easily resolved by pulling out that code and putting them into the Graphics.cpp file and then using macros to surround the platform specific code. While it is possible to separate it into separate files, I don’t believe any of the changes are significantly large enough to do so: with one exception: the InitializeView() function. But it is at the end of the file, and with a well said comment, I believe it could still remain in the file with a macro.
Lastly, I added a second triangle to make a rectangle, being careful to maintain the proper winding order.
Though the idea of encapsulation is pretty straightforward, going through the code and separating it out into its interfaces and implementations took the majority of the time.
Thanks to Zeno who helped me when my platform specific implementations weren’t working, also for answering C11 standards questions for me as this is the first time I have used them, and being someone I could bounce ideas off of. In particular, I completely forgot that the platform specific files had to be excluded from the others’ build. I literally just did that for some files two days ago, but that’s why I think it’s more efficient to work along side other engineers – even while working on separate projects. They frequently can help you quickly jump the hurdle you’re not seeing that’s right in front of you because your brain is too busy trying to solve the problem at the end of the track.
GPU DEBUGGING
Graphics debugging can be difficult (as is anything that you have to see or that you don’t get results until run-time), but VS has a cool built-in GPU debugger for d3d, and for openGL I chose to use the open source RenderDoc. For the last part of this project I took images of my game using the graphics debuggers. Although I couldn’t get all the images I wanted.
VS Graphics Analyzer for D3D
Here are two from the VS Graphics Analyzer. (You’ll notice that the pipelines is empty. That’s because every time I tried to use it the GA would crash.)
RenderDoc for OpenGL Graphics Debugging
This is literally the farthest I got with RenderDoc. The moment I try to open a log file I get the RenderDoc Error Reporter. On another computer the program crashed before the game could even load.
Why They Didn’t Work
I tried the VS GPU Analyzer and RenderDoc on three different computers and none of them worked: My laptop win8.1, desktop win7, and my work computer which is win10. I suspect the firewalls and restrictions on my work computer kept the graphics analyzers from being able to do their injections. It seems that the VSGA and RenderDoc aren’t compatible with the libraries we’re using on Windows 8.1 and 7, and there doesn’t seem to be a fix. However if you’re on Windows 10 (and don’t have strict restrictions on it), then I believe these tools are a great asset for graphics debugging.
Optional Challenge: Draw a House
The question was “Can you figure out how to draw a house?” The answer: yes.
Really, you can draw anything you want out of triangles if you’re willing to take the time to code all that in. All of these were hardcoded, and even though I thought I had winding order down, I still made a couple mistakes the first time (It does help to write it out first!). I just did a couple more simple ones: an arrow and a pinwheel.
Of course in a real game you aren’t drawing the triangles out by hardcoding their positions. There are pipelines that handle drawing and rendering images to the screen; but way down below all those cool graphics: triangles.
Nancy Games 