If you are working on a game chances are you will work with DDS (DirectDrawSurface) files. DDS file is a standard format by Microsoft to store image/textures. It can store single image, mip maps, cube maps, etc2 and can have standard DXT compression technique.
If you want to understand various DXT variants (DXT1, DXT1a, DXT3, DXT5), you can check out:

// Function for converting depth to view-space position
// in deferred pixel shader pass. vTexCoord is a texture
// coordinate for a full-screen quad, such that x=0 is the
// left of the screen, and y=0 is the top of the screen.
float3 VSPositionFromDepth(float2 vTexCoord)
{
// Get the depth value for this pixel
float z = tex2D(DepthSampler, vTexCoord);
// Get x/w and y/w from the viewport position
float x = vTexCoord.x * 2 - 1;
float y = (1 - vTexCoord.y) * 2 - 1;
float4 vProjectedPos = float4(x, y, z, 1.0f);
// Transform by the inverse projection matrix
float4 vPositionVS = mul(vProjectedPos, g_matInvProjection);
// Divide by w to get the view-space position
return vPositionVS.xyz / vPositionVS.w;
}

The basic idea is that if we have a matrix that transfoms from View Space to Clip Space, we just take the inverse of that matrix and multiply it with the clip space position we should be able to get back the view space position. But my biggest question was why did we need to divide-by-w (in view space) at the end?
I thought the order is like this:

It turns out the MATH WORKS OUT! I can't see why this is happening logically, but mathematically it's correct! It's amazing, I learned a new thing today!
My next question is, if I want to bring it to World Space instead of View Space, do I need 2 matrix multiplication steps such as the following:

This works because if you pay attention to ViewMtx_INVERSE, the fourth column is actually (0, 0, 0, 1) which basically doesn't modify the w. That's why you can do divide-by-w at the end and still get the correct result!

When we develop games (or any apps really), we typically have at least two configurations: DEBUG and RELEASE. Furthermore, we usually add a bunch of debug code that should only be visible in DEBUG mode, but not in RELEASE (FINAL) mode.
I don't know about you, but I am spoiled by C++ thinking that when we switch on the optimization, the compiler should strip empty method. However, having been in the game industry for a while, I have the mentality that we can't really assume anything until we confirm it. So, I made a test creating an empty function and function with conditional attribute.

To my surprise, C# compiler DOES NOT strip empty method!! Luckily, function with DEBUG conditional is stripped as expected. After further investigation, I found out that there are actually 2 compilers at work here: C# and JIT (Just-In-Time) compiler. C# compiler turns C# code to IL at compile time and JIT takes the IL and generates the native machine code at runtime. In addition, if you start your application from Visual Studio with the debugger attached (F5) then all the JIT optimizations will be disabled even if optimization is enabled.
In Writing High-Performance Managed Applications : A Primer, it explains how we can view the optimized JIT version of the code. After stepping through the code, it's relieving to know that actually JIT strips out the empty method.

As many of you know, StringBuilder.Append(int) method creates a garbage. This is bad for XNA games that do this conversion every frame. In this article, I provide one implementation to convert int to string without creating garbage. I tried to be as efficient as possible; if you find better way to do this, please let me know.

During shader development, packing/unpacking from one format to another format is very common. Sometimes, the purpose is to support older graphics card and occasionally, it is more efficient to do so. Below are growing list of packing/unpacking methods in shader.