Monthly Archives: September 2014


The purpose of the fourth assignment was to start dabbling in per-material and per-instance shader constants ( values which could differ between two meshes using the same material) and to create a more refined asset build system.

I added a constants table to my Material files, which would have more tables containing constants segregated by data type. For this assignment, this involved adding a single table for Float3 values:


VertexShader= “data/vertexShader.hlsl”,
FragmentShader= “data/fragmentShader.hlsl”,


Constants =
g_colorModifier = { 1.0, 0.5, 1.0 },

Here’s how the rectangle looks with the above value of g_colorModifier


Changing g_colorModifier to { 0.0, 0.5, 1.0 } gives the following result:


This was an example of a per-material constant. Different meshes could use the same material with slight variations in its constant values.

I changed the architecture of my Material class as well, so that it now maintains a std::map  for the vertex and fragment shaders which associates constant values in each shader to a handle which can be used to change these values at run time. This map is populated automatically at the start of the program, based on the values in the “Constant” table in the Material file.

The other constant value was a per-instance value, g_meshPosition_screen, which controlled the position the rectangle was rendered on screen. It would be set each time we rendered our meshes based on the position of the mesh, which in turn would be updated every frame depending on User Input. I created a Mesh class which stored a pointer to a Material associated with it, along with a Vector3 to keep track of its position.

The arrow keys can be used to change the position of the rectangle on the screen.

We also added a GenericBuilder class to our project, so that we can start moving towards special build processes for different asset types, instead of building all assets in the same way. This builder simply copies the assets to our game directory at the moment.

Here’s a zip file of my assignment: ClickHere.


Some Final Art!

Our artist Rob made some AMAZING art for our game.


Seeing the art in the game, and the game finally come together has lifted everyone’s spirits 🙂

I’m currently working on getting a couple of weapons coded for our game. One of them is a pull gun, which pulls your enemy towards you ( duh!), and the other is an AOE nuke, which paints the area around its impact with minions. I’ll post a little more about them in the next blog


For our 3rd assignment, we had to render a rectangle, and also create our own Material file format.

We moved on to IndexedPrimitives for this assignment, so that instead of explicitly specifying the position of the vertices to be rendered, we filled in the vertex buffer with the vertex information and specified the triplet of indices that would give us the vertices to draw a triangle.

Assignment 3-Saumya



The Material file would be an easy to read/edit file which would define the parameters of a particular material to be applied to a mesh in our game. For this assignment, the Material file would only contain information of which vertex and fragments to use to render the particular object. Here’s how I set up my material file.





VertexShader= “data\vertexShader.hlsl”,
FragmentShader= “data\fragmentShader.hlsl”,




This file specified the location of the vertex and fragment shaders associated with my default Material. I chose to put the shaders in a separate table in order to keep the file clean and readable ( since I expect the file to grow significantly in the future).

My Graphics class now has a std::map of Materials , which associates a string to a Material pointer. This map is populated at the start of the program, by reading through a “MaterialList.lua” file which holds the names of all the materials used in the game.

This map helps me look up the path of the .mat file associated with a particular Mesh during rendering and get the pointer to the Material object, which enables me to set the vertex and fragment shaders accordingly!

I’m currently creating and destroying a new luaState for each luafile I need to read/execute. I plan on changing this in the future.

Here’s a zip file to run my current build: Click Here

Menu System

I developed a menu system for our game this week.

Ron already had a MenuManager set up, which had a dictionary which mapped strings to delegates. You could load a menu by calling the LoadMenu(stinr i_menuName) function, and it would call the appropriate delegate based on the string.

I build on this system, and added a Dictionary, which also associated a string with a delegate. Whenever I would load a menu, I would call the corresponding delegate. Each of these delegates would populate an array for Actions. Hence, as I moved through the menu, I would keep track of the action it was pointing to, and when the ‘A’ button was pressed, I would call the Action currently being pointed to. These actions would mostly cause the game to quit, load a different level, show the help menu/options menu, or go back to the previous menu.

We could now press start during the game ( which would pause all user input, and draw the pause menu), and move through the pause menu ( as you moved through the menu, the button being pointed to currently would be shifted to the right, to let the user know his current selection)


Our second assignment had us mess with the vertex data we used to render the triangle in our first assignment. We would now pass in an additional parameter to the vertex buffer, namely color. Each vertex of the triangle was assigned a different color. As a result of the interpolation of the color values between the vertices, we ended up with a colorful triangle, whose individual pixel colors were based on their distance from each of the vertices.



The colors I chose for my vertices were (0,0,255), (125,125,125), and (255,0,0), or Blue(Center), Grey(TopRight), and Red(Right Center).

Here’s some info on the data used by DirectX to render the triangleSaumyaMukul-PIX


The events tab shows the calls made to DirectX, and the PreVS tab has more info on the vertices passed to DirectX ( their index number, their positions, and the color they are associated with!)

The other part of the assignment had us use Lua scripts to take over the Asset Building process. We integrated lua into our build process, which involved learning how to call C++ functions from lua and vice versa. I was really fascinated by how arguments and return values were exchanged between C++ and lua.

Estimated time spent working on this assignment: 11 hours

Here’s what I ended up with 🙂 : Click Here

Input maps

I worked on inputs this week. Ron already had a basic framework for them, which he called the InputMap. It basically had a number of strings which corresponded to the different buttons and axes we used in our game. We needed this encapsulation so that we could change the strings contents and have them map to a different button or axis, while still retaining the variable name ( and hence not having to change the code anywhere else). So, we could get the righttrigger axis for the first player by the following code

float RTvalue = InputMap.RightTrigger(int i_playerID)


The first assignment was aimed at getting us started with a well organized Visual Studio solution and setting up a simple build pipeline. We set up the solution in such a way that the final game executable, as well as intermediate .obj and .exe files would be generated in separate folders, all inside a temp folder so that we could delete all generated files by simply deleting the temp folder. The simple build pipeline for this assignment generated copies of the assets used by the program, in the final game folder.

I decided to make my Game a class, since I felt it would be more organized, and would leave my main function clean as well. I made a singleton class for the graphics code, creatively called “Graphics”.

The Game was in charge of initializing the game Window and setting up directX through the Graphics class. The main function would then call its update loop, which consisted of rendering, and checking whether the user had shut the window down, each frame. Finally, at the end of the program, it would exit cleanly by handling the shut down events needed by directX and the Main Window.

Here’s a link to a zip file of my assignment : Click Here

[EDIT] Here’s a revised link ( does not crash if you delete the data folder): Click Here

Architecture, and GameModes

We have managed to get a basic architecture for our game in place, which consists of a central object which keeps track of the game’s elements.

This object sets up the controls, the screen division ( did I mention that we’re not doing networking right now? It’s on the backlog, we might get to it if we get the other stuff in place), the input handlers, checks for end states based on the game mode and also draws menus.

All the credit for the architecture goes to Ron, I was very impressed with it. I managed to learn a few new things about C# as well, such as delegates and events ( which we are using right now to handle Health changes and Level transitions).

I came up with the GameMode logic.  Each game mode is represented by an integer, with each bit representing an end condition. For example, if the first bit represents time limit, and the second represents a kill limit, while the third represents a territory control limit, the DeathMatch gamemode would be something like 00000011 ( so time limit and kill limit are enabled), whereas Territory control mode would be represented by something like 00000101 ( so time limit and tile count limit are enabled). Based on these bits, the game would check to see if the end game state had been attained.

We could use the other bits to represent other end states that need to be checked. I really liked what I had coded. It seemed efficient, and clear to the reader.