Assignment 5: Human Editable Settings.ini and Lua for Graphics Building (and more…)

NancyNewren_ExampleGame 05

The user can now set resolution via the settings.ini file. All shaders are now built with lua code. I also added some more pretty sprites. Hooray! (Simple one-click download. Once downloaded, unzip, play the executable, enjoy!)

About the Project

I added a settings.ini file to the download which allows users (like you!) to set the resolution of the game. The file is originally contained as part of the UserSettings project inside the engine, but is copied by Visual Studio into a predetermined output directory, and then the lua asset build script copies it into the final game directory. This is pretty neat as it makes updating the resolution practically trivial: meaning no code recompilation is needed. As everyone’s device is different, this allows the user to set their desired resolution. It also means that there is more we could add to the settings.ini file later that the user could then change as they desired, removing the developer from the updates at hand. As a developer, QA, or even level designer, this also makes it fast to test different resolutions for different platforms.

For gamers, hot loading data into the game takes the settings.ini idea a step further. Hot loading data into the game means (at least how I’ve done it) that game periodically checks for new data while it is running and can import the data during run-time. I actually prototyped a game at EA that did just this. So the player could drop a file specifying more data like having a dinosaur model in the game, put the information in the hotload folder, and then their dinasour would  appear in the game. It was really neat, especially as a player, to see data you created become part of the game during run-time.

Before the settings.ini (or the default resolution):

After a tweak to resolution variables in settings.ini:

The other thing I did was implement a lua script for building the graphics assets (and copying files into the final game directory). In debug I merely copy the lua build assets script which makes debugging and testing simpler. But in release the lua code is compiled and then ran. This makes running the lua code more efficient, but it also makes it hard to debug because, well, this:

It doesn’t really matter in this example though for compiling vs plain text as the assets build lua file is run at build time and so compiling the lua file only helps to build faster. It doesn’t affect the player.

Of course I didn’t compile the settings.ini file into binary because that would completely defeat the purpose of having a human-editable file for changing settings for the game. If a human can’t read it, they can’t edit it!

I find the interesting bugs…

So I ran into an interesting bug: I was getting an “incorrect function” error. It was obvious that there was a path error, but this error message was really throwing me off. After hours of trying to resolve (Zeno and my TA Ameya both helped me in trying to resolve the issue), but ultimately I was stuck. I finally talked with the developer (my professor) and he discovered a bug in his code: he was returning the wrong string variable for the error. Once that was resolved we quickly resolved my bug which to my chagrin was the same bug as his: I too was also returning the wrong string variable.

Assignment 4: Utilizing Game and Render Threads for Improved Performance

NancyNewren_ExampleGame 4

Now we’re getting somewhere! The game can now render an arbitrary amount of sprites per frame. In this instance there are four. I think it’s pretty. 😉 (Simple one-click download. Once downloaded, unzip, play the executable, enjoy!)

About the Project

The simplest part of this project was letting the game submit to the graphics a different background color. This data is cached until the renderer is ready to render.

eae6320::Graphics::SubmitBackgroundColor(eae6320::Graphics::DefaultColor::lightGray);

I moved all the sprites and effects out of the graphics class and created them in the game. Because rendering takes a significant portion of time in games, we utilize threads to render while the game computes data. In this implementation the game submits to the render data it wants rendered, which is then cached by the renderer until it’s ready to render. When the game is done submitting it lets the render thread know. When the renderer has finished rendering all the previously submitted data it cleans up that data and let’s the game know when it can start submitting again. This is the point where the threads sync, which is done each frame. At sync the render thread swaps the submitted cache and the cache it just cleaned. It then uses this data to render, and the game has a clean cache to submit data too. Submitting to the render thread is simple, just send over the sprite with its corresponding effect:

eae6320::Graphics::SubmitToRender(m_sprite[0], m_effect[0]);

Each rectangle needs it’s own sprite, but an effect can be used multiple times. So the second sprite uses the same effect:

eae6320::Graphics::SubmitToRender(m_sprite[1], m_effect[0]);

I am using the stl’s vector to create as many (up to the maximum number that a vector can hold that is) sprites and effects as I want. It’s then fairly trivial to submit sprites and effects to be rendered to the render thread.

Even though we are passing reference pointers around for all the sprites and effects, since we can send an arbitrary amount of sprites and effects to render the memory overhead can get large if we haven’t optimized their size. I had previously optimized the sprite and effect size by ordering member variables from largest to smallest. However when I saw the sEffect size I realized I was passing around unnecessary data. I removed it and the size dropped by the size of the variables I removed.

OpenGL
sizeof(sSprite): 12
sizeof(sEffect): 24, 16

D3D
sizeof(sSprite): 24
sizeof(sEffect): 64, 48

I’d only ever looked at the size of objects via code, so it was interesting to me to look at it during compile time. I opened the Debug->Windows->Immediates window in Visual Studio, put in an obvious breakpoint and when the debugger paused, I typed in “sizeof(ObjectName)” and the immediates window printed it out. Thanks to Mark Smith for helping me find the Immediates window.

I am having a recurring Visual Studio run bug. I spent quite some time trying to resolve it. J.P. tried to help as well for a while with no luck. I finally reverted all our changes, closed VS, and rebuilt and the bug went away. The thing is that I’ve done this multiple times and it keeps coming back. Running and building in Visual Studio haunt me and give me terrible nightmares.

Assignment 3: Graphics Platform Independence, User Input

NancyNewren_ExampleGame 03

This game has TWO sprites with different effects! Aww, the awesomeness!

(Simple one-click download. Once downloaded, unzip, play the executable, enjoy!)

About the Project

In this project I made the graphics functions platform independent by creating a cView class. This class handled initializing, cleaning up, clearing, and presenting. Then all platform dependent code and variables went into cView.[platform].cpp files.

Thus the call for clearing the back buffer code now looks like this:

//When rendering
view.ClearView();

I used a color struct to pass colors, and used this to create the pretty gray background (as opposed to black).

sColor lightGray(0.8f, 0.8f, 0.8f);  //alpha is set to 1.0f when left blank

Assignment 2: Effect and Sprite Encapsulation, GPU Debuggers

NancyNewren_ExampleGame 02

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.

Assignment 1: Project Setup and Simple Animation

NancyNewren_ExampleGame_01

This game is a simple triangle animation. The player need not do anything but enjoy the beautiful movement of this simple shape.

(Simple one-click download. Once downloaded, unzip, play the executable, enjoy!)

About the Project

This was a fun one to program. It was very straightforward and when it came time to do some math, I was excited! The object was to simply animate a triangle on screen using the given solution files and graphics project.

To animate the triangle I took the sin of time to give it a smooth vacillation. Sin’s limits are [-1,1] though, so to animate the color I essentially took the absolute value of sin and changed the value of the green between 0 and 1, as color is represented as rgba in [0,1]. Because I didn’t want to call a math library to do a simple absolute value, to calculate the abs(sin()) I used the mathematical definition of absolute value:

f(x) = x if x >=0
f(x) = -x if x<0

Thus in my code I have something like this:

absSin = sin >=0 ? sin : -1*sin;

Now this does give a sharp point to the animation, but I wasn’t interested in smoothness at every point along the graph and like the quick turnaround. However, if I had desired a smooth animation I would have halved the peak size and moved the graph above the x-axis (to get that [0,1] range) as follows:

moreDifferentSin = 0.5*sin(time) + 0.5;

Instead of moving the triangle around I decided to make it shrink and grow by multiplying the abs(sin(time)) to the position of x for all vertices. Since the middle vertex was already at (0,0), it remained in place. The result: continuous similar triangles of varying size and color.

I definitely struggled getting the project to build. But I learned quite a bit about setting up dependencies and building while doing it. I was even able to quickly help some classmates as their errors came up because pretty much everything I could do wrong, I did. But now I recognize the errors and know what to do for them. The class discussion boards were definitely helpful in resolving this, but especially the two hours I spent with the professor JP after posting two discussions myself finally got my build working. He did this late on a Saturday night and that is definitely going the extra mile.

I first built on my Windows 8 laptop, knowing that the project code was written for Windows 8+. However my classmate, Cornelia, also did a test for me of the project on Windows 7. His was a VM though and he didn’t get it working. JP asked me to test on my desktop and I found that it worked! I had already installed all the necessary programs and SDKs previously, but didn’t need to install anything else to get it working except the game itself. It was exciting to see it work on my Windows 7: for all configurations and all platforms (we’re using openGL and D3D). Now I don’t have to upgrade. Hooray! 😉

Working with the Graphics Project

We were given the entire solution minus the graphics project which we then had to add in to the rest of the solution and then add the appropriate references and dependencies to it and the projects that called its functions within their cpp files. I added Graphics as a reference to ExampleGame_, and Applications.

I did not add it to the Tools project however, even though Graphics is referenced by the ShaderBuilder files, because all references to Graphics were enums, which aren’t necessary to link. For example, in Tools/ShaderBuilder/cShaderBuilder.cpp it reads:

Graphics::ShaderTypes::eType shaderType = Graphics::ShaderTypes::Unknown;

Which references the Graphics library, but doesn’t call a function which is used in the cpp file, so it’s not necessary to add the reference.

Expectation of Class

Based on the class so far I expect to learn quite a bit about programming graphics. JP (my professor) was the first person to ever explain how to tell which way the triangles were wound in such a way that I completely understood and understood with confidence. I’ve also learned the difference between creating a solution build, and a building a project. I never understood why you would do one over the other before. (Essentially you build projects when you want to just build it and its dependencies. You build solutions to build everything in the solution, whether or not it is listed as a dependencies. This is especially helpful to know if you have projects that rely on the output of each other, but don’t need each other to build. I don’t think I’ve ever had a setup where this was true before, but it makes sense in large projects that you wouldn’t want to set dependencies on other projects just so they build together. The upside to this is if you change a part in one project you only need to build that project and whatever depends on it, and not anything else. In very large projects that can save a lot of time!) I’m definitely expecting to learn lots more C++ programming insights, visual studio shortcuts, and become a much more proficient programmer.