Engineering II - Assignment 9 - Maya Exporter - PIX Instrumentation - Basic User Settings

Assignment 9 - Maya Exporter - PIX Instrumentation - Basic User Settings

ZIP LINK

Assignment9.zip

Write-Up

The basics of this assignment required three specific tasks to complete.

First was to set up a Maya Exporter, and allow Maya to convert to a mesh format our game engine supports. Second, was to include PIX instrumentation for debugging. Finally, we used a basic ".ini" file to allow the user to alter the size of the window, up to full screen.

Technical Write-Up

Maya Exporter

The first setup for the Maya exporter required implementing my mesh type. This required reading in the mesh file from Maya, and converting it to my format of meshes. A particular mesh I created in Maya was called "pyramidMesh.lua". The name of the mesh must include "Mesh.lua" as the type, because this is how my pipeline recognizes the mesh.

If a new mesh was generated and renamed as "pyramidMesh.lua" it would replace the current mesh used in game. This mesh is placed on two objects in the game. You would need to replace the mesh file in the Assets folder, but as long as the name is still "pyramidMesh.lua", you will have no further changes to make.

The game currently is rendering five objects. Two pyramids, one fish humanoid, one floor plane, and one sphere. The pyramids are using the same mesh, but one is using a blue ray material, and the other is using a sun material. The sphere is also using the same sun material as one of the pyramids. The fish humanoid initially uses a scales material, but if you press the "E" key it will switch to the sun material. The floor plane is using a stainless steel material.

The keys to move the fish humanoid are:

Up Arrow - Moves Fish Humanoid away from the camera

Down Arrow - Moves Fish Humanoid towards the camera

Left Arrow - Moves the Fish Humanoid left of the camera

Right Arrow - Moves the Fish Humanoid right of the camera

The keys to move the camera are:

W Key - Moves the camera upwards

S Key - Moves the camera downwards

A Key - Moves the camera leftwards

D Key - Moves the camera rightwards

This allows you to see that the material and mesh components of the in-game object can be altered with a simple pointer movement. This is shown in the image below:

The left section of the image shows the fish humanoid with the scales material, and the right section of the image shows it using the sun material.

Overall in the scene, the pyramid on the left has the sun material, while the one on the right has the blue rays material. The sphere, with the sun material, is above the fish humanoid. The fish humanoid is floating above the floor plane with the stainless steel material.

A key point to recognize is that if the material is going to show appropriately with the UVs, the UVs must be adjusted in Maya. I do not know how to adjust the UVs in Maya for the meshes being exported, so they do not look correct in game.

PIX Instrumentation 

The second setup is for PIX instrumentation, which allows the engineer to generate the scene, capture a frame of rendering, and see what function calls are being made. It also allows the viewer to see what objects are being rendered, view the vertices, indices, and UVs of each object.

The instrumentation added to the current engine code allows the creation of your own custom events to wrap the engine code for easier visibility in PIX. This is currently being used in Debug mode only, as you wouldn't want to generate these calls in Release mode.

The two key pieces of information that is currently grouping function calls is the setup of new materials, and the drawing of new meshes. The material setups and the draw calls can happen every frame, and will show up in PIX. See the image below:

The left section of the image shows PIX using Debug mode and shows the "Set Material" event which is capturing each function in that event. The image also shows the "Draw Mesh" event, capturing the Draw Primitive function call. The right section of the image shows PIX using Release mode, and shows no events being called.

These events can be used throughout your code to help you more easily view specific function calls, group code that is important, or ignore function calls you do not want to see.

User Settings

Finally, the last implementation is the use of basic user settings for the engine. This allows the user to alter the "gameSettings.ini" file, in the Game directory, to change the screen size, or set it to full screen for their current resolution.

This required some additional code for the user settings to be altered. After implementing the included code, some reformatting was required. This happened in the Windows Program class and the Graphics class.

If the user sets the width and height to values less than zero, it sets them to default "800 x 600" (width x height). If the full screen variable is set to true, the width and height are ignored and the game is set to be at the current full screen resolution.

This file is generated in the game folder after the game is built. This allows the user to alter the .ini file that exists for that build, but still saves the original file in the original folder. This was done by a custom build tool for the in the .ini file. This prevents anyone, including myself from altering the original file from it's initial setup.

Realized Learning Moments

With the Maya materials I realized I had to save pointers to all of the meshes and materials, and this would allow my entities to change meshes and materials when needed. This required some reformatting of my mesh, material, and graphics classes. It is more robust now, but will require additional reformatting for the game to handle the entities in a more isolated manner.

The PIX implementation helped remove extraneous statements in Debug mode. You were able to find the needed functions or calls more quickly than hunting through "IDirect3DDevice9::..." descriptions. I was going to try and use more of this in my build for other parts of code, but would require using Direct3D code in those sections. This is for rendering purposes, and we'll leave that focus there.

The user settings was a fairly simple setup. There is an odd issue when using Alt-Tab to change to another window, but this causes the game to crash. If you use the "X" in the top right corner, or hit the escape button it will cleanly exit from the program.

This homework provided a stronger understanding of weak points in my architecture. I have realized points in my graphics code that needs to be isolated in another class, and will make it easier to read, and more difficult to alter by accident.

I need to change the ".lua" extension of the mesh and material files to appropriately fit ".mesh", ".material", or something more easily readable and usable.

I was also really happy to include this old fish humanoid model I made in Maya. It was my first attempt, and I thought it was fun to see in my game engine.

Time Used

Reading: 3 hours
Write-Up: 0.5 hours
Technical Write-Up: 1.5 hours
Coding: 9 hours

Post 36 - New Ideas

The entire team had a discussion about design and passion of what's occurring in the game. So, the team has broken up into small groups and are working on some quick prototyped ideas to playtest. All of these ideas must be completed by Monday night at 7:00 p.m., so we can include this as part of our weekly build.

The goal of these iterations is to find some more fun in what we've built. I think we heard some great ideas, and I look forward to their outcome.

I pitched an idea that I believe was poorly explained. The idea was about one player trying to break into the other player's castle. I didn't mean to be altering the main game focus so much, it was just a brainstorming moment that I had with another team member, and we wrote it down.

I know I offended a friend on the team, and I didn't mean to. I looked back on it and realized my mistake with this idea. 

Currently, my focus is on fixing bugs for the build, and completing some of the backlog items we have. It's going pretty well.

We have only a few more weeks before we have our bi-yearly open house to show off the program, and our hard work in our games. I'm looking forward to getting feedback from everyone, and seeing how we move forward from here.

Engineering II - Assignment 8 - Texture Addition - Updated

Assignment 8 - Texture Addition - Update

ZIP Link

Assignment8.zip

Write-Up

Technical updates are listed below.

Technical Write-Up

Updated the UVs for my cube mesh and floor mesh. I have added the textures to them, and they are displayed below:

Realized Learning Moments

I experienced a memory pointer issue, so I had to fix a function that was receiving a value and now receives a reference to it. Also, the I broke down the cube with a paper cutout to see how the texture would layout, and what vertices/indices would be drawn. It helped me understand the placement better.

Time Used

Additional Coding: 1.5 hours

Engineering II - Assignment 8 - Texture Addition

Assignment 8 - Texture Addition

ZIP Link

Assignment8.zip

Write-Up
The basics of this assignment were to create a builder class to load all of the needed texture files, and then have a texture added to a material, which will show up in the current build.

Technical Write-Up

The first portion of the file is to have textures in one format saved into your data assets in the DDS format. This is done by creating a build class to focus on building texture files. I added the needed file statements inside the assets to be built,

I would place a texture of the image on my cube and plane, and show it here, but I am still implementing a needed value for them, the UVs. The UVs are setup inside of the vertex information. The texture information is then handled via DirectX calls.

Here is a image of it, without the texture on it, but with a smiley face I drew using MS Paint.

Once the UVs are setup you can create the texture to a variable using the DirectX function CreateTextureFromFile. This function specifically requires DDS textures, which is why forced the textures into that format.

The UV texture are available to the fragment shader. From this point on, the texture color is sampled and applied to the final image when rendered.
Realized Learning Moments

I didn't prepare enough time for this assignment. Rewriting the lua information for UVs is taking longer than expected. I will update the blog with another post, showing those changes.

Time Used

Reading: 1.5 hours
Write-Up: 0.25 hour
Technical Write-Up: 0.25 hour
Coding: 3 hours

Engineering II - Assignment 7 - Mesh Building Pipeline

Assignment 7 - Mesh Building Pipeline

ZIP Link

Assignment7.zip

Write-Up
The basics of this assignment was to have a mesh class that is capable of being built during the build step, and saving that information in a binary file. Once that is done, you then can read the binary mesh information for each entity using that mesh. The mesh file needs to be human-readable, which is shown in the write-up below.

Technical Write-Up

The mesh file is human-readable, as it is split to show the number of vertices and indices of the mesh, and then lists the position and color of each vertex, and then lists the order to draw the indices. An image of the human-readable floorMesh.lua file is below:

 

When the file is stored in binary it looks like below:

 

This helps reduce the size of the file, in my case, from 666 bytes to the binary file size of 96 bytes. I used a builder file to run during the build step, rather than load the files into binary tudring run-time. 

Realized Learning Moments

I found that I needed to rewrite most of my mesh file, my graphics renderer, and then create all of the lua file to read the files. I used PIX to huntdown the issue of nothing drawing.

The issue was determined to be somewhere with the indices values. All of them were storing the indcies[0] value of "0". The values should have been different. I stepped into where the indices were being read by the lua file, and struggled to find the issue. I learned more about the actual lua function "lua_pushinteger(...)", because of the parameters being passed to it.

I then used debugging with breakpoints to confirm the vertex and index counts, as well as the values stored in the vertices and indices buffers. This helped me understand how it's being stored and used. I have realized that I am going to have to restructure my game code and rewrite some of my engine code.

Time Used

Reading: 3 hours
Write-Up: 1 hour
Technical Write-Up: 1 hour
Coding: 12 hours

Post 35 - IGF Submission

I have been a bit late on these blog posts, but that is due to last weeks submission to IGF!

We have submitted our build for the Independent Game Festival, and we are see where things for future builds.

We are not stopping, and will continue moving forward. We will hold a meeting to discuss it's current state and what we would like to iterate/change for the future.

Check out our game on our site at Hostile Territory!

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