[Glitch toString];

I've been working at cPanel for almost 4 years now, and I must say I've enjoyed every moment of it. Ignoring the stress and crunch that is found almost anywhere you go of course.

My co-workers at cPanel are great, and they've really made my stay here really feel like home. However, it is time to move on for me. While I've enjoyed many of the challenges I've faced while helping to design, and implement, the cPanel for Windows product (cPanel Server Suite) I've decided to revisit my beginnings and my reasons for beginning to study computer science in the first place. :)

I've accepted a position at Pi Studios, where I'll be given the opportunity to work with game industry veterans and help bring some kick ass games to gamers around the world.

This really is a dream come true for me, as I've wanted to work in the game industry since playing Quake for the first time.

This blog has been going in that direction for a while now, but hopefully now that I'm going to be immersing myself full-time in game development (yay for not having to 'make time' for it anymore) I should have more steady (and more interesting) new content (and a new design hopefully as well).

On an almost unrelated note, I picked up GTA IV last night. So far, it is the best GTA I've played. I'm so glad it's not placed in the 80s.. and I've been very surprised by the amount of details placed in the game. Like, I swear I heard my car radio make that annoying BzzT BzzT sound prior to my cell phone ringing. :D That makes me happy. Blood splatter makes me happy too. Especially blood splatter on the side of a car, after clipping 3-4 pedestrians after slamming on a very touchy e-brake. Can't wait to play some more. :)

A week or so ago someone asked me if I had any experience with the Streaming SIMD Extensions (SSE). While I often answer the question "What's your favorite programming language?" with "Assembly!", I sadly have never had the opportunity to make use of SSE, nor did I truly know the specifics of the extensions (like, just where I'd use it).

So, to counter this deficiency, I've been poking around learning more and more about them. Which lead me to realize just how out of date my assembly books are. So I did what I normally do when that happens -- I ran to Amazon to correct the problem. Only to find that not only are there very few assembly books published recently, but of the 2-4 books worth getting only one has a decent coverage of SSE (or so it seems..). Most don't seem to cover the floating point unit very well, or x64 at all. Not that it's a huge task to look at the instruction set and figure it out, but if you're writing a book on assembly why not cover topics that modern assembly usage would exploit? I mean one book released in the past 2 years even had a chapter dedicated to TSRs, is that even relevant today?

I can't imagine an author would spend the time writing a book on assembly without covering, x64, floating point, and at least up to SSE 3. SSE 3 has been around since Intel's Pentium 4 Prescott chips, which have been around since 2004. Even that is possibly on the verge of rendering a book out of date very shortly, considering SSE 4 is in C2Ds, and 5 was announced last Aug.

Almost everyone would agree that no one is writing full applications with assembly anymore (at least outside of the embedded worlds), so why wouldn't an assembly book contain the most up to date (read: advanced) material? No one is going to drop out of C/C++ to 'speed up' their code with simple 32bit instructions that their compiler is probably far more skilled at optimizing.

It boggles the mind.

I'm going to pick up the one book that looks decent. I'm also going through Microsoft's info on the Visual C++ SSE intrinsics. So, maybe I'll have some XNA GS vs. Native performance showdowns soon. >:)

Ozone Riders. The upcoming hit from TeamAwesome!™, expected to be released some time this summer, in Paris. ;)

The game has the player orbiting around the Earth fixing the ozone holes, and battling nasty corporate waste disposal drones. Naturally, from a graphics perspective this places a TON of emphasis on the Earth. For an object that will always be in frame, there cannot be any obvious (or slightly obvious) faults with the model, its texturing, or it's lighting. If there are, the player will have to stare at those faults, the entire game.

So, what makes a cool looking Earth? How do we render it in such a way that players will enjoy looking at it? I only have one answer to these questions, and it is, I have no clue. I do however, have some guesses. :)

There are a couple things that when I think of the planet's view from space make me giddy from a visual perspective. One of those things is the atmosphere. That nice blue halo around the planet just screams cool. A visual of the earth from space, without that halo is a fake, I don't care who's stamp of approval is on it. Even an obvious photoshop is better than no halo at all.

The other thing that makes me happy, is detail. From almost every NASA photo I've seen of the planet, you can make out some pretty crazy detail despite the insane distance. I'm talking NASA photos, not NSA photos. So, I don't mean like license plate details, I mean being able to see mountains and terrain detail.

Then, once we add in the fact that our players will be orbiting the Earth, we have to take into account another aspect of the planet and it's relationship to the rest of the solar system. The sun, can only reach one side of the planet at a time. So, as a player, I wouldn't expect for it to be noon in Paris, and Houston. Major point deductions for that.

So (the point of this post), I've been working on the shaders for our planet model for our game. With these things in mind, I thought I'd share the evolution of our planet. :) So without further ado,

A Planet Is Born

Here we have the Earth, fully textured, with a single point light for the "sun". As the sun's light fades a texture is blended in to supply emissive light to mimick the earth's night time look.

Here you can see the night effect a little better.

Here we have the earth, with specular lighting on the oceans and clouds. The clouds slowly rotate over time to create a fairly nice animation. I think this is another important aspect of something like this that will be a major focal point to the game. If an object that is constantly in the center of view doesn't change in some way, it's boring. No matter how beautifully rendered it is, it will get stagnant quick. Something as subtle as clouds moving will give the player minor "oh hey! look at that!" moments. Which add to the cool factor for objects like this.

Finally, this is where I'm at now with the shaders. Here we have the added atmosphere, and normal mapping on the ocean. The effect here is another slow animation that makes the oceans look alive. As you're flying around the planet, the specular light coming off of this adds a whole new level of realism.

I'll probably put up a couple posts next week detailing how the shaders work, along with my new found love for FX Composer 2. :)

On a side note, I've decided what I'm going to do with my "Two week topics". My original plan was to start from the beginning, introduce shaders, and then work up to advanced uses of them. Unfortunately, since this is the first time I've really tried to do a series of articles, I had a huge problem ordering my thoughts enough to work out a game plan for it all. So, while I put that all together (in the background) I'm going to start putting up articles on "middle ground" things like post processing, or like this Earth. Once I get my act together for my original plan, I'll start posting it. :)

Another side note, Go TeamAwesome!! :D

My appologies to all you blog fans out there, my first attempt at my article series is going horribly wrong. I guess that's what I get when I decide to do it on a whim without planning, or beta testing. ;) I am not giving up, but I am going to take a couple days to rework the way I was planning the articles out. Expect a better start in the next couple of days. I think the first change, is removing the time frame. It just means I have to keep myself motivated enough to keep up with it. :)

I've been battling a couple of colds the past few days. I may or may not have the flu, and/or strep. My cultures were all negative. My only guess is that some bigger, more powerful, single celled organism kicked the flu and strep bacteria's asses a la spore, because I sure as hell feel like I have both.

This is the first time I've had an actual fever in over 10 years, my wife will confirm that. So it reminds me of being a kid. Yes, it sucks that bad.

On a lighter note, I just got a few nVidia books today. The Cg Tutorial, GPU Gems, GPU Gems 2, and GPU Gems 3. Up until today, I hadn't seen these books in person. I figured they'd be just like the ShaderX series, or Game Programming Gems series. I own both series, which is why I put off getting the GPU Gems books so long. Having them in my hand now, all I have to say is.. Holy crap. These books are probably the nicest, best print, computer graphics books I have seen to date. Full color pages, no jumping to the middle of the book for the color plates, beautiful diagrams, crisp fonts, syntax highlighting. I cannot wait for the next GPU Gems to come out.

You know you're a book geek when you open the cover of a book like this and get giddy.. without even reading the material. Which, the material is awesome as well. The first book alone covers a nice selection of topics. Interestingly enough, nVidia has also just released their first GPU Gems book online for Free. :)

This is my first "Two Week Topic", so I'm going to take a couple posts to get the feel for how I want to approach this. Lets pretend I said I'd start this week and not bring up that I'm a week late.

For topics like this (Shaders), that are fully discussed and documented, I won't waste time duplicating the already well written material on the internet and in books. Instead I'll give a brief overview and provide ample resources for further reading. Topics that I'll delve into that don't seem to be documented as much, I'll gladly dive as deep as needed.

Shaders: Introduction

In the beginning there was the fixed-function pipeline. This is what most people are familiar with who have experience with OpenGL and/or DirectX in a basic, academic, setting. The fixed-function pipeline provides developers with a limited number of options for rendering output. These options can be combined to perform a wide range of capabilities but as one would expect with something that is often described as 'limited' there are a lot of things that just aren't possible with it.

Taking the place of the fixed-function pipeline is the programmable pipeline, which picks up where the fixed-function pipeline leaves off by allowing graphics programmers the ability to use their own algorithms for implementing the limited set of algorithms provided by the fixed pipeline. These programmer provided algorithms are implemented via Shaders.

Depending on your graphics API (OpenGL, DirectX 9, DirectX 10, etc.) shaders come in 3 flavors:

• Vertex Shaders - A vertex shader gets run for each vertex sent to the GPU. These can be used to apply 3D to screen translations for vertices. Generally the output generated by a vertex shader (Translated coordinates, vertex color, etc.) is sent to the Pixel Shader.
• Pixel Shaders - A pixel shader is run for each pixel that gets colored by a surface (or line) represented by the vertices sent to the GPU.
• Geometry Shaders - Geometry shaders are the new kids on the block. They allow the addition and removal of vertices on the GPU and are currently only available in DirectX 10.

By making use of these shaders we can have an amazing amount of control over the rendering of our scenes. For example, in the fixed function pipeline lighting was generally calculated per-vertex. This means that all lighting for the pixels rasterized from a triangle was interpolated from the vertices. By using pixel shaders, we have complete control over each pixel rasterized. So, we can implement per-pixel lighting which will smooth over the pixels in an accurate way. We can even perform adjusted lighting to simulate surface detail using normal mapping, or parallax mapping. By rendering our scene first to a texture, and then rendering that texture to a screen aligned quad we can perform post processing such as Motion Blur, sepia toning, distortions, or any number of seemingly never ending effects.

Where to go from here

Over the next two weeks I'll be using DirectX 9.0c to demonstrate how vertex and pixel shaders can be written, and integrated into XNA GS, and C++ programs. I'm going to be using HLSL, and FX Composer 2 for the next couple of posts. Over the next few weeks (I plan on spending some time with shaders) I'd like to also touch on GLSL, and Cg. Some of the topics I'd like to get to after the basics include, Lighting (Basic, Normal Mapping), and Post Processing effects (Blurs, Color tricks, Displacement).

Next post will focus on vertex shaders.