GDC and Vinyl stagnation

I just got back from GDC.  It was pretty cool, and I can check it off my list of big gaming conventions I'd like to attend one day.  Just leaves E3 now and I'll have pretty much all the big ones, including TGS.  That said, pretty much no one seemed too interested in hiring interns this year.  I had way more fun just finding triple A studio programmers and asking them questions and picking the other big schools students brains about their programs.  USC, Digipen and RIT were all there in pretty full force.

Next year should be awesome though, since everyone seemed pretty interested in hiring entry level stuff, and Vinyl will be almost complete.  Also, I plan to buy the nice pass and actually go to a bunch of the talks.  I went to one, but it was more about selling their product that automates LODs than talking about how they implemented their software.  Still, looked like a cool product.

Anyways, the reason I mentioned Vinyl stagnation in the title is because sadly, we haven't gotten any real work done on it since the industry panel.  One thing led to another and there just hasn't been any time.  Basically due to delays we didn't even do the industry panel until the week before spring break, when it should have been 3 weeks before.  So by the time the teams were settled we had a week off.  Then a week on again before GDC, and now another week after that where half our team, myself included, will be in Montreal.  That leaves about 3 weeks left in the semester to get into alpha.  Looks like we'll be doing a bit of  summer work.  That's okay though, I'm still more excited about this idea than any of the other projects I'm working on.  They just sadly had to take precedence for the time being.

Speaking of which, the main thing that has been occupying my time lately is the reason we're going to Montreal.  A bunch of us are in a game prototyping competition that Ubisoft Montreal is putting on.  Since we leave on Tuesday we've spent the last two weeks crunching out the end of the prototype.  Last weekend we went from a tech demo with empty levels to basically a full blown game in about 25 hours of work time.  This weekend, shortly after arriving back from SF we polished everything we could and tweaked a few more things.  The game looks amazing now and I can't wait to show it off in Montreal.

Still, I can't help but thinking maybe I put a bit too much on my plate this semester.  4 weeks til summer though, can't wait to just have a job for a few months.

Real Time Graphics Asg09

It's so shiny!!

Seriously, look at how shiny that dudes face is, it looks especially creepy on the floor.  It's like you can almost see an entire galaxy in his face, or maybe just a nebula, I dunno.

Anyway, this assignment was fairly straight forward, just ran into a few bugs.  Mainly fixing the camera to work how it was described in the email broke a few things.  I believe the problem was resolved by negative a value.  I'm not entirely sure why we needed to change anything, since from what I understood we were just passing in extra data that we didn't need originally.

Other than that the environment map worked just fine.  DirectX has great support for it.  I wonder, do people invent these technologies and then DirectX includes them in the next major release or how does that stuff work?  I thought environment mapping was a fairly new thing, but we're still rocking DirectX9, which is almost 3 years old now.  Then again, the teacher mentioned Shenmue 2 doing it and that was like 2002...

Moving onto the second part of the assignment.  Making anything behind the first sphere wobble according to a tangent function.  I dunno why we like tangents so much, probably cause of the asymptote that breaks up the squiggles.  In order to do that we had to all the non transparent geometry, save that to a texture and then draw the transparent stuff using that texture as a background.  Then copy it all back and actually draw it to the screen.  Here's the screenshot showing the texture before the transparent entity in PIX.

I was having trouble figuring out where to place the draw copy it back code, because when I stuck it in my transparency if checks it never fired since none of the entities were technically marked as transparent.  This led to a nice black screen, even though I could see all the stuff being rendered properly in PIX.  Sherly helped me modify my if check so that I got everything but the floor, turns out I was now copying the texture over to the backbuffer, but was doing it twice so I overrode the floor with the second entity.  It was kinda neat to see each draw call in PIX and watch the exact moment the floor went bye bye.  Fixed that one with even more modifications to my if check.

Those were the only real problems, the actual graphics part of the assignment was pretty straightforward.  Which is odd cause they are both pretty bizarre ideas.  Reflecting something that isn't actually there has a surprisingly cool effect that is very noticeably different from just specular.  I assume you would generally want the environment map to mirror whatever is in your skybox though.  I was also blown away by how we achieve the squiggly ball affect.  Literally saving the entire frame and then drawing over it seems like a ridiculous amount of extra work to do every single frame.  That said, we are essentially doing that anything with each mesh being drawn on top of the previous one, but we're only drawing the fragments we need each time.

The teacher said we could only do it once or it'd get too slow, but I wonder if we could pull it off again considering how little we're actually doing in our scenes.

Anyway, source code!

Real Time Graphics Asg08

This weeks assignment was pretty cool actually.  I always had an inkling of what bump mapping was from being around games all the time, but upon actually implementing a simple normal map I'm a little blown away by what you can do to a surface by just altering some normals.  Here's the assignment for the random googlers.  And here's what the assignment ended up looking like.  Guess which one is specular.

I'm not entirely sure what to include in this writeup, usually I talk about all the horrible things that went wrong, but this one was pretty straightforward.  The hardest part was properly scaling the cube in Maya to output a cube at the same size as our hand coded cubes.  Changing the Maya exporter to output bitangents and tangents was exactly the same as how we were already output the normals.  The actual fragment shader code was pretty simple too, just modifying some normals with the new values.

I did find it interesting how DirectX handles multiple textures per mesh.  I figured we'd have to explicitly call SetTexture with the specific texture name, their way is much nicer.

Other than that I spent a bunch of time making new text files and cleaning up some things.  I took the specular exponent out of the scene file finally, even though I wasn't even using it.  Additionally I decided on an expected texture type of 0 to be just a texture and 1 to be texture and normal .  This way I can just do a simple int compare in the update loop, might not be the most human readable though.  Spoilers, 2 will probably include environmental maps.

I also spent a lot of time figuring out how I broke my specular lighting awhile ago.  Apparently I was passing a zero in for light intensity, which when multiplied with my specular lighting went to zero.

Anyway, here's the code.

Vinyl Greenlit, Administration discussions ensue.

So Vinyl got through the industry panel, because its awesome.  Our team has now more than doubled in size.    Sadly, two of the four got cut, including Ludology, which I thought was a fantastic idea and my fallback plan in case Vinyl got axed.  Ah well, such is life, Cosigners and Vinyl absorbed the other teams and now we finally get to start planning to make a game that isn't just a prototype.

We spent most of the first week debating platforms and engines.  A lot of the feedback we received suggested we do a mobile game.  We kind of like that idea, but we wanted to use Crytek and they cannot easily deploy to anything, but a PC.  The more we debated it though, the more we decided we could make a better game on PC and that trying to hit mobile because it's a better market is pointless.  We are a student game and we should be trying to execute a cool proof of concept.  If we have some time when we're done we could look into porting to Unity and deploying a lesser version on mobile.

On the other hand though, it looks like we may have to pony up a few hundred thousand Euro's to get a reasonable Crytek license so we might end up using Unity from the beginning.  We expect to spend most of our time figuring our how to process individual song sound waves anyway, which will be engine independent, and then using that data to generate levels.

So far we've looked into a few different opensource softwares to do that and a Unity library.  Looks like I might have to brush up on my partial differential equations as well.  Who knew those things actually had a use.

I'm gonna mess around with those over spring break and report back with some actual engineering stuff hopefully.  Catch yah on the other side.