Thursday, October 16, 2014

Engineering II - Assignment 6 - Asset Building and Precompiling Shaders

Assignment 6 - Asset Building and Precompiling Shaders

ZIP Link

Assignment6Debug.zip
Assignment6Release.zip

Write-Up

The basics of this assignment were to complete builder functions using the GenericBuilder project information from Assignment 4. The other portion of this homework is to compile the shaders prior to the build stage.

I included the debug and release versions of the data files and executable, so you can see the difference formats the hlsl files are compiled as. The debug format stores more information, while the release format is storing as little additional information as possible.

Technical Write-Up

For the current homework to precompile the shaders, fragment and vertex shaders, the LUA file that is read needs to define what executable files to run. I have altered the AssetsToBuild.lua file as shown below:


This is separating tables for generic assets and then different shaders, such as fragment shaders and vertex shaders. It is easily readable and provides simple understanding for the next section.

The initial step was to confirm that the files copied straight from source to the target folder. I focused on using the simpler reading of the file, which is the primary focus for the AssetsToBuild.lua file show in the previous image.

Realized Learning Moments

All of these shader files will be precompiled prior to the run sequence, meaning that the build step will require more time to set up all of these compiled files, but is faster than having the run step handle these 'build step' sequences. This then only requires the build sequence to build the required assets on the build sequence.

*The current state of this build is not using the 3D cube and movement from Assignment 5, and is focusing purely on the 2D square from prior assignments.

Time Used

Reading: 3 hours
Write-Up: 1.0 hour
Technical Write-Up: 1.0 hour
Coding: 4  hours

Engineering II - Assignment 5 - PLACEHOLDER

Assignment 5 - PLACEHOLDER

ZIP Link

Assignment4.zip

Write-Up

The basics of this assignment were to alter the vertex shader to alter the color value across the entire object, in this case a rectangle. The default values are a gray-scale rectangle, with different gray values at each vertex.

Then we were to check for user input via the keyboard, and move the rectangle around the screen.

Finally, we were to include a generic builder (GenericBuilder) builder project, which will simplify future projects for building different assets.

Technical Write-Up

So, I was able to edit the current code and get it to draw a gray-scale rectangle correctly. The values for doing this involve editing the Material file including a section for constants. I included mine as shown below:



 I initially was going to use the g_colorModifier in a table of constants. I had trouble trying to push and pop values from the table when reading it using lua functions. I had to comment it out to get it to work. I will work on this for future iterations, as I did not provide myself with enough time to complete this assignment.

The g_colorModifier is table of values that holds an amount for the amount of red, green, and blue to be used for the pixels on the gray-scale triangle. This color modifier that is being checked for allows multiple materials to be saved with different color values. This will modify the color for the vertexShader of the item with that material being included on it. Multiple objects/entities could contain different materials, and be altered depending on their vertex shader, fragment shader, and now by constant values such as a color modifier.

Here are a couple of images showing the different colors on the rectangle.



The second step in this process was to include code that would check for user input, and update the position of the rectangle object. I started the project using the material to hold the position and velocity of the object, but this was incorrect according to our assignment. We were not to hold the position values for the object in the material. The material shouldn't worry about it's position in the world.

I did not complete this step, as I did not provide myself with enough time. I will complete this in future iterations, and here is how I will do it. I will create an Entity object which stores the position and velocity values. This entity will store a material, containing all of the information it needs to draw itself. This will include the shader paths and constants needed. The Entity will also hold a value for it's "mesh" which holds all of locations of vertices to be drawn for itself.

There will be timer and input classes to detect the player inputs, and move appropriate rates with respect to the timer. It will be checked on the Game project's update call altering the Entity's position. With this position being altered, you will have to add this offset to the vertex values, causing the object's vertices to be altered when they are drawn to the screen.

The third item we were to complete was adding in a GenericBuilder. I did not provide myself enough time to complete this section. From what I understand, this section will allow us to implement new projects for new assets quicker, with less hassle. It will allow you to copy the new asset type from the source to the target assets location. The templated generic class is used to be called in a virtual 'Build' function, to be re-written for that new builder class.

Realized Learning Moments

I didn't realize I would be stuck in the section looking for the material constants for the vertex shader. The example was well explained on the site, but I did not understand where these elements were being used in prior code.

I did not provide myself enough time to finish this assignment. I need to prepare more time for this and the future assignments.

Time Used

Reading: 2 hours
Write-Up: 0.5 hour
Technical Write-Up: 0.5 hour
Coding: 2  hours

Monday, October 6, 2014

Post 34 - Playtest Feedback

This blog post is in reference to our playtest on 10-3-2014.

We received feedback about our controller inputs using the XBox360 controllers. The "FPS" or first-person-shooting format was not a major hit, but some liked it. The two "TPS", or third-person-shooting, formats were the most popular. One involved a camera movement fix, and one allowed the camera to clip through the environment. I am sure one of those will be our focus.

Our team appears to be communicating more. I know that some have not felt any communication is going on at all. I have sent emails, met in person, and discussed things the best I can, so I cannot do much anymore other than learn telepathy. I am not sure I can make that happen.

As for the game feedback, it wasn't much fun. People struggled to understand what they were supposed to do, how things worked, etc. There wasn't much communication to the players that would be intuitive for a "shooter" game.

Our professor, Ryan, explained that there isn't anything fun going on. He doesn't understand how to move through the environment, he doesn't know what to shoot, and he doesn't know why. There was a timer, he could change the color of some of the ground, and then the timer ended. He didn't recognize any health meter, he wasn't sure if he was injuring the other player, so he didn't know what his goal was for the match.

I don't think our producers understood what he was saying. After giving us this feedback they kept explaining that this playtest was focusing on finding which controller worked best. I don't think they understood that the game isn't fun.

We will be reviewing the content of the feedback in the next class session. Hopefully this will help give us goals before Fall break kicks in, and we can finish this before the IGF submission.