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: The following library/tools are proven to be useful: If you ever need to write your own source code, the following links can be your starting point (don't just copy and paste, some of them have bugs):
Matt posted an excellent article about reconstructing position from depth. Check out his article here: http://mynameismjp.wordpress.com/2009/03/10/reconstructing-position-from-depth/ He has the following function to reconstruct View Space Position from Post Clip Space Position:
// 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:
PosInClipSpace = PosInViewSpace * ProjMtx;
PosInPostClipSpace = PosInClipSpace / PosInClipSpace.w;
so, if we want to get back from PosInPostClipSpace to PosInViewSpace, we need to do this:
PosInClipSpace = PosInPostClipSpace * PosInClipSpace.w;
PosInViewSpace = PosInClipSpace * ProjMtx_INVERSE;
so, somehow we need to save the w in order to get back the position in View Space. Out of curiosity, I did the Inverse of Projection Matrix MANUALLY and work out the following:
PosInViewSpace0 = PosInPostClipSpace * ProjMtx_INVERSE;
PosInViewSpace = PosInViewSpace0 / PosInViewSpace0.w;
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:
PosInViewSpace0 = PosInPostClipSpace * ProjMtx_INVERSE;    // First Mtx Mult
PosInViewSpace = PosInViewSpace0 / PosInViewSpace0.w;
PosInWorldSpace= PosInViewSpace * ViewMtx_INVERSE;    // Second Mtx Mult
It turns out, I don't need that. I can just multiply with ViewProjMtx_INVERSE and divide-by-w at the end, i.e.:
PosInWorldSpace0 = PosInPostClipSpace * ViewProjMtx_INVERSE;
PosInWorldSpace = PosInWorldSpace0 / PosInWorldSpace0.w;
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.
using System;
using System.Diagnostics;

namespace OptTest
{
    static class Debug
    {
        public static void EmptyFunction() { }

        [Conditional("DEBUG")]
        public static void DebugFunction()
        {
            Console.WriteLine("Debug Here");
        }
    }

    static class Program
    {
        static void Main(string[] args)
        {
            Debug.EmptyFunction();

            Debug.DebugFunction();
        }
    }
}
This is how the disassembly look like in DEBUG mode:
        static void Main(string[] args)
        {
00000000  mov         qword ptr [rsp+8],rcx 
00000005  sub         rsp,28h 
00000009  nop              
0000000a  mov         rax,7FF001B1DF8h 
00000014  mov         eax,dword ptr [rax] 
00000016  test        eax,eax 
00000018  je          000000000000001F 
0000001a  call        FFFFFFFFF9B384F0 
0000001f  nop              
            Debug.EmptyFunction();
00000020  call        FFFFFFFFFFEC9A70 
00000025  nop              

            Debug.DebugFunction();
00000026  call        FFFFFFFFFFEC9A78 
0000002b  nop              
        }
Ok, everything works as expected in DEBUG mode, i.e. empty function and function with DEBUG conditional is not stripped. Let's take a look the RELEASE mode assembly:
        static void Main(string[] args)
        {
            Debug.EmptyFunction();
00000000  mov         qword ptr [rsp+8],rcx 
00000005  sub         rsp,28h 
00000009  nop              
0000000a  mov         rax,7FF001C1DF8h 
00000014  mov         eax,dword ptr [rax] 
00000016  test        eax,eax 
00000018  je          000000000000001F 
0000001a  call        FFFFFFFFF9B28280 
0000001f  call        FFFFFFFFFFEC9800   // Why is this still here???

            Debug.DebugFunction();
        }
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.

public static class StringBuilderExtension
{
    private static char[] charToInt = new char[] { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9' };

    public static void Swap(this StringBuilder sb, int startIndex, int endIndex)
    {
        // Swap the integers
        Debug.Assert(endIndex >= startIndex);
        int count = (endIndex - startIndex + 1) / 2;
        for (int i = 0; i < count; ++i)
        {
            char temp = sb[startIndex + i];
            sb[startIndex + i] = sb[endIndex - i];
            sb[endIndex - i] = temp;
        }
    }

    public static void AppendNumber(this StringBuilder sb, int number)
    {
        // Save the current length as starting index
        int startIndex = sb.Length;

        // Handle negative
        bool isNegative;
        uint unumber;
        if (number < 0)
        {
            unumber = (uint)((number == int.MinValue) ? number : -number);
            isNegative = true;
        }
        else
        {
            unumber = (uint)number;
            isNegative = false;
        }

        // Convert 
        do
        {
            sb.Append(charToInt[unumber % 10]);
            unumber /= 10;
        } while (unumber != 0);

        if (isNegative)
            sb.Append('-');

        sb.Swap(startIndex, sb.Length - 1);
    }

    public static void AppendNumber(this StringBuilder sb, uint unumber)
    {
        // Save the current length as starting index
        int startIndex = sb.Length;

        // Convert 
        do
        {
            sb.Append(charToInt[unumber % 10]);
            unumber /= 10;
        } while (unumber != 0);

        sb.Swap(startIndex, sb.Length - 1);
    }
}

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.

Packing Float to RGBA32

float4 packFloatToRGBA32(float f)
{
    const float4 pack = float4(1, 256, 65536, 16777216);
    return f * pack;
}

Unpacking RGBA32 to Float

float unpackRGBA32ToFloat(float4 rgba)
{
    const float4 unpack = float4(1.0f, 1.0f/256, 1.0f/65536, 1.0f/16777216);
    return dot(rgba, unpack);
}
This convention below is applicable to Direct3D and XNA matrices

World Matrix
Given a position and basis vectors rightup and look of an object, a world matrix can be formed by the following arrangement:


View Matrix
Given a position and basis vectors rightup and look of a viewer, a view matrix can be formed by the following arrangement:


Projection Matrix
Given field of view FOVaspect ratio, near clip plane Zn and far clip plane Zf, a perspective projection matrix can be formed by the following arrangment: