An Introduction to HLSL (Part I)

In a previous article we looked at how to use custom shaders when rendering models, or as post-processing effects when applied to an entire scene. Now let’s look at how to build our own shaders.

For this project, I’ll be using the same code from the Intro to Effects and Post-Processing article. This code is already set up to drop effects on models and to use effects as post-processors. So you’ll need to already know how to use effects in both contexts in order to follow along.

We’ll move through the non-HLSL stuff quickly. First, add a new effect file to your project. I keep all of mine in a content folder called FX. XNA builds a simple effect file template for you.

Let’s start with this template. If you build and run your project, you see something less than stellar.

So let’s begin with this simple effect file and try to figure out what it’s doing.

First of all, every effect file consists of a vertex shader, and a pixel shader. In short, the vertex shader is able to manipulate a vertex property, like its location and its color. The pixel shader is receives the output of the vertex shader, and is able to perform per-pixel operations, which can mean lighting, coloring, texturing, multi-texturing, and so on.

This represents two of the three stages in the pixel processing pipeline. The missing stage, the geometry stage, sits between these two. XNA does not support geometry shaders, so we don’t need to worry about this stage. All we need to know is what happens between the vertex and pixel shader stages. Basically, once the vertices get transformed, colored, and so on by the vertex shader, the rasterizer converts the triangles in our primitives to pixels ready for the screen. Our pixel shader outputs the color of each pixel.

So if we look now at our default effect file, we can start tearing it apart.

Let’s look at the header first.

This is where we specify what parameters we need passed in to our effect. Remember, that looks like this:

That sets up the matrices that the vertex shader is going to need to to translate the raw vertices to their final, screen coordinates. Also note that the HLSL float4×4 and the XNA Matrix types are equivalent. We don’t need to do anything special to get our Matrix values ready for HLSL.

Next we’ve got a couple struct definitions:

Here we simply specify what the input and output of our vertex shader looks like. XNA will automatically pass in the correct values, and the correct amount of values, here. In this default effect, we’re only asking for the vertex position. We’ll use our three matrices to translate this position and then return the translated position. Consequently, our input and output structs are identical. Note here that a HLSL float4 type is identical to an XNA Vector4 type. Our vertex shaders may also process color. In that case, you’d want to add a float4 to the input and output structs for a RGBA color value.

After the struct definitions, we actually define out vertex shader function.

This is quite simple. We define a function that takes a VertextShaderInput struct as a parameter, and returns a VertexShaderOutput struct. Internally, it multiplies — via the mul() function — our vertex by the world, view and projection matrices, and returns the resulting vertex location. That’s it. This is something you’ve done using BasicEffect a bunch of times, and here’s what it looks like in HLSL.

Next, we define the pixel shader function:

Our pixel shader function returns a float4 (we could have defined this as a struct called PixelShaderOutput or something similar if we wanted). There is one new thing here though, the COLOR0 at the end of the function header. In fact, we saw that earlier, with POSITION0. What does that mean?

These are semantics. They basically define common elements between our game code, and our HLSL. Remember I said that the vertex position would get automatically passed in to our vertex shader without us having to do anything special? This is because the POSITION0 is a semantic meaning vertex position. The 0 at the end means, “the first one”. We can define POSITION1, COLOR3, or whatever depending on how many inputs to the function we’re going to have.

As for the pixel shader function, can you figure out what it does? I basically ignores the pixel position returned by the vertex shader, ignores whatever color data was associated with that pixel (since we never received the colors of the vertices, we couldn’t have done anything with it anyways), and returns a color value. In this case, it returns pure red with alpha 1.0.

The last step is to wrap this up into a technique, and a pass for that technique:

We have one technique, called Main, which has one pass, called Pass0. And then we just tell it to compile a Vertex Shader 1.1 and a Pixel Shader 1.1 out of the two functions we’ve defined for each.

Well, that is the most basic introduction we could possibly do. We looked at the bare minimum of vertex and pixel shaders and made sense of the most basic effect file imaginable. In part 2, we’ll go a little deeper and actually make a shader that does something.