Development Diaries, Volume 3

Posted by Alex Jordan on

When I posted my last Development Diary, I had gotten lighting working on my test shader, but movement wasn't working quite as I'd expected it. Well, not five minutes after posting the Diary, I got movement working correctly. Again, it came down to what order I was feeding instructions to the shader. But nobody wants to read a Diary that consists of, "Hey, I got the order right. Here's a video. Things look exactly the same. Please read my blog, I'm desperate for page hits." No, I decided I'd learn how to properly instruct the Super Awesome shader that FX Composer 2.5 spat out for me.

And I couldn't figure it out. At all.

Then, several days of busyness and horrific work stress set in, during which I had no time to program. In case you're interested, the highlights of the last few days:

  1. I did not die.*

Compare that to the highlight of today:

This day is certainly an improvement.**

You'll notice correct lighting, movement, normal mapping, and even ambient lighting. So, if that isn't the Super Awesome shader, what is it?

It's the test shader. Since I couldn't figure out the correct way to instruct the Super Awesome shader (which I really should still figure out, as quitting should never be an option), I researched the math behind normal mapping and plugged it into my test shader. I also figured out an ideal method for ambient lighting (how to have soft shadows) that my game can use, and I incorporated that too. When I was done, my test shader was no longer for testing purposes. It's almost ready to roll for the actual game.

Unfortunately, it's very, very inefficient. It does a lot of calculations that should be handled outside the shader. (A shader is composed of two components: a vertex shader, which is run for each vertex in a 3D model, and a pixel shader, which is run for each pixel on the screen that the 3D model takes up. Any calculations in the pixel shader will run every time a pixel needs to be rendered on the screen, whereas calculations in a vertex shader will only run once per vertex, and there's always a lot less vertices. However, any calculation that can be handled before you run the shader is even better, since there's only one draw routine. Think of a simple cube, with 8 vertices... 1 draw routine < 8 vertex shader passes < tons upon tons of pixel shader passes.) But since my goal was to get the shader working (which, you can see, it does) I can now go back and make it efficient.

So I have texturing, lighting, movement/rotation, and normal mapping all working on my shader. The next thing I'll be doing is adding falloff to the lighting, since game light sources should have a limit on how far the light will travel. Not sure if I'll post a video of that, since it'll look the same as ambient lighting, only rendered on surfaces that are actually facing the light but are too far away. And once that's taken care of, it'll be time to start using my shader on the models of the surface of the Earth I created for Around The World.


*Not dying did include a nice coop play session on Marvel: Ultimate Alliance 2 with my roommate and two of my other friends last night. I played as How Is She Not The Most Overpowered Woman in Comics, my roommate Eric played as Yes He's Fucking Popular Goddammit Can We Please Have Someone Else On The Team, Brian played as Captain Republican (these days, who else would start a rebellion against the government and vaguely claim they're doing it 'cuz of "Patriotism"?), and Other Alex played as Not That Interesting In The Movie Guy, after which he switched to

The three large vodka and cranberry juices I had during the playfest also really, really helped with the whole not dying thing.

**I'll also be uploading to YouTube in HD from now on, especially since many development videos might need to highlight subtle effects such as normal mapping that might be indecipherable in a lower-quality video.