Game Graphics Assignment 3

this assignment wasn't too bad. I had extra time early and decided to get this out of the way. I had done all of this in game engineering already. In that class we had to do per vertex and per pixel lighting with both diffuse and specular. So doing per pixel diffuse lighting was simple. All of the specific function calls i just looked at my old code for.

To move the camera use wasd (there is no forward and backward, the camera always faces 0, 0, 0)
up: w
down: s
right: d
left: a

To move the light use the numpad
numpad8: Up
numpad2: Down
numpad4: Left
numpad6: Right
numpad7: +Z, towards the camera at first, then passing and going behind the camera
numpad9:  -Z, away from the camera

The main problem i had is that i forgot how assert works. I had put a function call in the assert statement. So when i went to release mode that call was optimized out. Other than that it went fairly smoothly.

One thing i did do that i wasn't sure if i should have or not was i took out the color from the vertex. We aren't using it and without the color it is 32 bytes instead of 36 bytes. I can easily add it back in if we use it later.

Everything should be working. Although i can't always tell if the lighting is correct or not.
http://www.eng.utah.edu/~codyh/u0789429-Graphics-Assignment-3.zip

I wasn't entirely sure what you meant by the texture resource in pix. i double clicked on the texture and got a picture of it. So i think that is what you mean.

CryEngine

I am loving this engine so far. i have broken a few things, but overall i love it so much more than UDK.
It has an sln file for visual studio so you can just open that up, look at the code and run it (once you set the launcher.exe to run on debug). At that point you can put a breakpoint in the code and walk through the c++ code of the engine. It is really nice to be able to see the code of the engine running, and follow it around.

I setup version control for the engine too. I am using perforce which i really love so far. Although one of the levels broke and cannot be loaded on one of the computers. Not sure how much of that was version control.

Also figured out how to work on the same scene as other people. If you are both working on different layers of the same scene, then you can both work and have the final include both of your changes. So we can divide the level into areas and parts, so i could be editing the spawn of the enemies and someone else could be editing the platforms. we both save our changes (they get saved to different files, one for each layer) and then when you load the scene it loads both layers. Much better than unity for that. Although there is no real merging, at least multiple people can work on a scene, as long as they are coordinated that they are not both making changes to the same object. One way to make sure of that is to check out the layer file you want to edit things in. that way you can see if someone has that layer checked out and don't edit it until the check it back in. We will see if the rest of the group works well with perforce or not, it isn't as easy as svn but it gives a lot more power.

Game Graphics Assignment 2

This assignment i completely reworked the structure of the code. renderer.cpp has about 50 lines of code now. i made a class for the camera, scene and geometry. I hope later assignments have us using multiple pieces of geometry because my code can handle any number of geometry.

I had to change cMainWindow.cpp and .h to make the WaitForShutdown function not const. I needed to do this for handling input, which changes the position of the camera and box, therefore they cannot be called from const functions. So now the Update function is not const, and there is a const Draw function that is called at the end of the Update. I could change it so the window calls the update then the draw, but eh.

I spent a lot of time reworking the code, but it was broken for a fair amount of time. I finally realized i was multiplying the matrix and the position in the wrong order in the vertex shader. so i was doing
mul(matrix, position) instead of mul(position, matrix).
once i fixed that the whole thing worked. Although i had a memory leek because i forget to release the vertex declaration, but found and fixed that too.

Everything should be working
Link to Code

To move the box you use the numpad
Move Left: numpad 4
Move Right: numpad 6
Move Up: numpad 8
Move Down: numpad 2
Move Rotate Clockwise: numpad 7
Move Rotate Counter-clockwise:  numpad 9

to move the camera use wasd

Move Left: a
Move Right: d
Move Up: w
Move Down: s

pictures:

Game Graphics Assignment 1

This assignment was mainly about learning to use the pipeline that John-Paul made. To be able to create another project tool and get it working with the pipeline. then to make some change to the vertex and pixel shaders.
The pipeline was different, but not too hard to understand. All of the rest (creating my own file format and shaders) i have done before. So overall the assignment went smoothly.

Link to code

Everything should be working. the vertex shader puts a sin wave through the position and moves them left and right (+- x value) based on the position on the screen. so the closer to the top the more it sways, and when it goes below the middle it sways the other way.
The pixel shader takes the color from the vertex shader (which is the x and y value as the red and green) and multiplies it by a sin wave so that the rectangle fades in and out.

The format for my "mesh" file is as follows.
[number of tries]
[x 1-1] [y 1-1]
[x 1-2] [y 1-2]
[x 1-3] [y 1-3]
--------------
[x 2-1] [y 2-1]
[x 2-2] [y 2-2]
[x 2-3] [y 2-3]
--------------


the line with the "------------" is a trash line for ease of reading, the parser just reads that line and forgets it. that also means that line could contain things line the name of the object and which triangle number that is. But atm it just separates the triangles.
Here are screenshots of debugging the vertex shader and pixel shader in Pix.

Pitch Week

Good start to the week with game pitches. I didn't work on mine very much and didn't practice it at all but it went fairly well. Since i already had a working prototype, it was pretty easy to turn that into a pitch.
watching the other pitches i was interested in some of them a lot. there were a few that i would rather make then my own game. the game vinyl sounded really fun to program. decomposing audio files and creating a level based off of the song could be really cool.
I am looking forward to seeing which games get picked. My biggest wish is that we can do the games in udk or cry (i favor cry a bit more). But i really want the experience of having a published game in udk or cry. I feel (and have heard) that those engines are much more similar to engines major studios use. Where experience with unity is good, but is not as impressive to industry professionals as UDK or cry. my preference for cry is that it is 5 years newer than UDK and being a student that publishes a game using the cryengine would be a very impressive statement to say. It also looks beautiful.