-Mike

The February 2010 DirectX SDK was released just moments ago. In this release, PIX for Windows has been updated with much fuller support for Direct3D 11 analysis. If you're using Direct3D 11, you'll definitely want to pick up this version of the DXSDK in order to be able to use great PIX features such as shader debugging and the mesh viewer with your Direct3D 11 programs. There are also a few new features that help with analysis of programs using any version of Direct3D.

Here's the official "What's New" announcement:

This version of the DirectX SDK contains the following new features, tools, and documentation.

PIX has much-improved support for analysis of programs that use Direct3D 11 features, including compute shaders, tessellation, and dynamic shader class linkage. PIX features such as pixel history, the shader debugger, the mesh viewer, frame counters, and screenshots now work for these Direct3D 11 programs.

The new "Playback Device" control in the Events pane enables the user to force PIX Direct3D playback to use the REF device.

Mesh viewer data can be exported to a CSV file by right-clicking the data tables displayed in the PreVS, PostVS, or PostGS views.

The texture viewer now supports the following additional formats:

• DXGI_FORMAT_D24_UNORM_S8_UINT
• DXGI_FORMAT_R24G8_TYPELESS
• DXGI_FORMAT_BC1_UNORM_SRGB
• DXGI_FORMAT_BC2_UNORM_SRGB
• DXGI_FORMAT_BC3_UNORM_SRGB

A minor revision to the library (version 2.02), includes a number of customer-reported fixes, optimizations, and improvements. Included are notable fixes to XMStoreColor(), XMQuaternionRotationMatrix(), XMVectorATan2(), and XMVectorATan2Est().

The Direct3D 11 Deployment for Game Developers article and D3D11InstallHelper Sample have been updated to include guidance for corporate network users in a locally managed Windows Server Update Services (WSUS) environment. For these developers, KB 971644 is not applicable and they should refer to KB 971512 instead.

Implementation changes to simplify voice reuse were made to IXAudio2SourceVoice::FlushSourceBuffers, IXAudio2SourceVoice::SetSourceSamplingRate, and IXAudio2SourceVoice::Stop. These changes enable titles to minimize the performance cost of creating and destroying multiple voices during the game.

We have optimized the codepaths for several of the less common channel mixing scenarios for mixing within the audio graph.

-Mike

Microsoft Expression Design is a pretty nice tool for laying out lines and shapes, and I was interested to see that it can export its documents as WPF XAML, which looked fairly straightforward to parse. I decided to see if I could use the XNA Content Pipeline to translate the XAML into lines and triangles that I could render.

XAML is based on XML, so I thought at first that I would parse the XML nodes directly with something like XmlReader. Then I realized that it was pretty easy to let Windows Presentation Foundation take care of the parsing, and just traverse the resulting WPF object hierarchy to get the path information. The XAML files I generated in Expression Design had a top-level Canvas object, which contained Canvas child objects for each layer. These inner Canvas objects had various Shapes -- the ones I was interested in were Paths. A method called GetFlattenedPathGeometry took care of converting any curves into line segments -- then I just had to iterate through the line segments and record the coordinates.

This was my first time attempting to extend the XNA Content Pipeline. It took a bit of background reading to get the hang of it, but it seems straightforward to me now that I understand the concepts. My Content Importer takes a XAML file as input and generates a "MyDataTypes.MyShape" object as output. I didn't need a Content Processor, since my app works with MyShape objects (there was no intermediate type needed). And thanks to XNA Game Studio 3.1's automatic XNB serialization, I didn't have to write a ContentTypeWriter or ContentTypeReader for MyShape.

One minor thing I had to deal with was a coordinate system change. Expression Designer and WPF treat the top-left corner of the document as the origin, with Y increasing as you move down the screen. I am more used to Y increasing as you go up the screen, so all my content was appearing upside-down at first (though I could modify my projection matrix to match WPF as one way to address this). I decided to have my Content Importer perform the Y inversion with a "Y = CanvasHeight - Y" adjustment.

Getting the line segments for a path was fairly easy. Getting the triangles for the interior of the path required a bit more work. Basically I needed a way to tessellate arbitrary convex polygons into triangles (this is sometimes called triangulation, since the term tessellation can mean other things).  Algorithms exist to do triangulation, but I was having trouble finding some pre-existing code to use. Then I learned that Direct2D has the ability to tessellate geometry, and decided to try using that.

Direct2D is fairly new, and is built into Windows 7. It can be installed on Windows Vista SP2 if you've installed the "Platform Update for Windows Vista" -- see KB 971644. If you're still using Windows XP, I'm afraid you're out of luck -- you'll have to find another way to triangulate shapes. Headers/libs for Direct2D are available both in the latest Windows SDK and the August 2009 DirectX SDK.

I wrote a standalone tool called D2DTessellate.exe to handle this triangulation task while importing content. It's written in C++, not C#, so I've provided a executable as well as the source code, in case you don't have Visual C++ or the necessary headers/libs installed. The tool reads a text file containing a list of points specifying a polygon, calls into Direct2D to tessellate it, then writes the resulting triangles to another text file. It's short and it works! My content importer invokes D2DTessellate.exe as needed for each polygon.

Note that the Content Importer needs to use WPF and D2D, but everything is just "MyShape" by the time the game loads the content from the Content Pipeline. So games that use XAML-based content with this method can still run on the Xbox -- the game itself doesn't have any direct dependencies on those Windows-only technologies.

Back in my XNA Game Studio game app, the main new thing I needed to add was a SimpleMesh class for drawing these lists of triangles associated with MyShape. I used non-indexed triangle lists, since that matched the data coming out of D2DTessellate. Since a lot of vertices are shared by multiple triangles, it would be possible to save a little space and improve perf by using index buffers and re-using vertex data instead of replicating it. My shapes were small enough that it didn't really matter. I created a spiffy zig-zag pixel shader as an example of a more interesting way to render the mesh triangles than a solid color. I also added a wireframe option to the test app, so you can see the tessellation.

I'm really happy with the result -- now I can draw shapes in Expression Designer, export the XAML, and easily import and draw it in my XNA Game Studio apps. Rock on!

-Mike

XamlDraw_1_0.zip

Since there still seems to be a lot of interest in it, I've updated my RoundLine code and released it on CodePlex. Here are the major changes from earlier versions:

• Updated for XNA Game Studio 3.0
• Uses shader instancing for improved performance: over 20,000 lines per frame at 60fps on the Xbox 360
• Drawing code is in a separate file from interaction code (using partial classes), so you can easily skip the latter if you don't need it
• Miscellaneous cleanup
• A small demo app is included

I hope you find it useful!

-Mike

The August 2008 DirectX SDK has been released. You can get it here.

Here are the PIX updates, as listed on the official "What's New" summary for the Aug08 release.

PIX Improvements

I've been working on a little arcade game to submit to the XNA Creators Club Community Games Beta. I finally finished it last weekend and submitted it Sunday night. It passed Peer Review and went live a few hours ago -- woohoo! It's not the most amazing game of all time, but it was still a lot of work to get all the details finished. I have ideas for more ambitious games to tackle soon...

Check out "Gemini 08" in the Games Catalog. Anyone with an XNA Creators Club Premium Membership can play it on the Xbox 360 for free! If you have feedback on the game, you can submit it here.

For more info about the XNA Creators Club and the Community Games Beta, check out this tour.

-Mike

Now that I've got the hang of quickly drawing lots of shapes with shader instancing, what should I draw? All that geometric repetition got me thinking about the artwork of M. C. Escher, which led me to this page about regular and semi-regular tessellation. The diagrams near the bottom looked nice, so I started playing with drawing similar images with XNA code.

Regular tessellations are tessellations of the plane with a single regular polygon. This is only possible with triangles, squares, and hexagons. Things get more interesting when you allow multiple kinds of polygons. Semiregular tessellations have the same sequence of polygons around each vertex, such as (4, 6, 12) for a square, hexagon, and dodecagon. There are eight possible semiregular tessellations.

To draw these, I first needed to make meshes for various polygons: squares, hexagons, octagons, etc. And I needed to be able to move and rotate them around relative to each other. Rather than gobs of the usual sines and cosines, I thought I'd try using turtle graphics, like the old Logo programming language. Here's my quick and dirty turtle class:

public class Turtle
{
    public Vector2 pos = Vector2.Zero;
    public float theta = 0;
    public void Reset()
    {
        pos = Vector2.Zero;
        theta = 0;
    }
    public void Fwd(float amt)
    {
        Vector2 delta = new Vector2(amt * (float)Math.Cos(theta), amt * (float)Math.Sin(theta));
        pos += delta;
    }
    public void RotRadians(float radians)
    {
        theta += radians;
    }
    public void RotDegrees(float degrees)
    {
        RotRadians(MathHelper.ToRadians(degrees));
    }
}

Tessellation_1_0.zip

I haven't written anything about PIX in a while. But here's a great article written by Brian Richardson at GarageGames about using PIX to track down a rendering issue. Nice job, Brian!

You can find the latest version of PIX in the March 2008 DirectX SDK.

 -Mike

A lot of my XNA-based programs draw many instances of the same mesh (such as RoundLines), with each instance having different position, rotation, etc. I had been submitting these meshes to Direct3D one instance at a time, which is not great for performance. Instanced drawing is a good way to get many copies of simple meshes on-screen faster, but it takes a bit of extra work. It's not too difficult, though.

The Instanced Model Sample is a great place to start learning about instancing. It's a little intimidating, though, to learn that there are three ways to do instancing, and they all require slightly different code and have different hardware requirements.

 

	Hardware Instancing	Shader Instancing	VFetch Instancing
Works on Xbox?	No	Yes	Yes
Works on Windows?	Yes (if vs_3_0)	Yes	No
Need multiple streams?	Yes	No	No
Need modified vdecl?	Yes	Yes	No
Need replicated VB?	No	Yes	No
Need replicated IB?	No	Yes	Yes
Need inline asm?	No	No	Yes
Max instances/draw?	Thousands	50-200	50-200

If you want maximum performance in every possible situation, you should probably implement all three methods. But, being a bit of a minimalist, I'd rather pick one method that works pretty well in all situations. The "happy medium" method seems to be shader instancing. It works on both Windows and Xbox, it doesn't require multiple vertex streams or inline assembly, and gives good performance. Hardware instancing and VFetch instancing have some advantages on their respective platforms, but shader instancing is giving me the speed boost I need without a lot of extra code paths.

In the Instanced Model Sample, a full 4x4 transformation matrix is specified for each instance. Since there are only 256 float4 registers available to the vertex shader, this limits the number of instances per draw to about 60. You can often get away with much less per-instance data, especially in 2-D. In my test program, I pass just four float values per instance: x, y, rotation, and hue. That all fits in a single float4, so I am submitting 200 instances per draw (I could have done closer to 256, but I want to leave room for some non-instance constant data). The per-instance data is going to vary depending on what functionality you want -- you might want a scaling factor or an alpha value, for example.

For shader instancing, the vertex declaration needs to have an element for the instance number, stored in a texture coordinate. The only other element I need for my program is position, so it is a pretty small vdecl:

public static VertexElement[] VertexElements = new VertexElement[]
{
    new VertexElement(0, 0, VertexElementFormat.Vector3, VertexElementMethod.Default, VertexElementUsage.Position, 0),
    new VertexElement(0, 12, VertexElementFormat.Single, VertexElementMethod.Default, VertexElementUsage.TextureCoordinate, 0),
};

int iVertex = 0;
for (int iInstance = 0; iInstance < numInstances; iInstance++)
{
    vertices[iVertex++] = new MyVertexElement(new Vector3(-1, -1, 0), iInstance);
    vertices[iVertex++] = new MyVertexElement(new Vector3(+1, -1, 0), iInstance);
    vertices[iVertex++] = new MyVertexElement(new Vector3(+1, +1, 0), iInstance);
    vertices[iVertex++] = new MyVertexElement(new Vector3(-1, +1, 0), iInstance);
}

int iIndex = 0;
for (int iInstance = 0; iInstance < numInstances; iInstance++)
{
    int iVertexBase = iInstance * 4;
    indices[iIndex++] = (short)(iVertexBase + 1);
    indices[iIndex++] = (short)(iVertexBase + 2);
    indices[iIndex++] = (short)(iVertexBase + 3);
    indices[iIndex++] = (short)(iVertexBase + 3);
    indices[iIndex++] = (short)(iVertexBase + 0);
    indices[iIndex++] = (short)(iVertexBase + 1);
}

VS_OUTPUT MyVS(
    float4 Pos : POSITION, 
    float Index : TEXCOORD0 )
{
    VS_OUTPUT Out = (VS_OUTPUT)0;
    float tx = instanceData[Index].x;
    float ty = instanceData[Index].y;
    float rot = instanceData[Index].z;
    float hue = instanceData[Index].w;
    ...
}

InstancedShapeDemo_1_0.zip

(Insert standard gosh-I-haven't-blogged-in-a-while blurb here)

(UPDATE: If you get an out-of-video-memory exception when starting the program, find the line of code that says "public const int numNodesToAllocate = 250;" and change 250 to a smaller number.)

I decided to improve my old XNA Mandelbrot set explorer to take advantage of the GPU horsepower available on PCs and the Xbox. It was a fair bit of work, but the end result is much more interactive and fun to use than the old version.

The core Mandelbrot set algorithm is a natural fit for a pixel shader. The harder part is making it incremental. Once you're zoomed in a fair bit, it can take hundreds or thousands of iterations to determine if a point is in the set or not, and it's more fun if you can zoom and pan around while progressively improving the image. So you want a program that can iterate a little, then move and draw, then iterate a little more. That is a little off the beaten path of the standard rendering pipeline.

I decided to use render-to-texture and ping-pong between two 256x256 textures. So for the first frame, the shader reads from texture A, computes some iterations, and writes to texture B. Then texture B is rendered onscreen. Then in the next frame, the shader reads from texture B, computes some further iterations, and writes to texture A. Then texture A is rendered onscreen. Then we repeat the whole process. (Life would be easier if we could read to and write to the same texture, but Direct3D doesn't work that way).

But instead of there just being one texture A and one texture B, there are a whole lot of them. The two-dimensional space is subdivided with a quadtree, and each node in the quadtree has a "texture A" and a "texture B." The program both iterates on and draws all visible nodes, every frame.

Also, what I'm calling "texture A" for one node is actually more than one Direct3D texture. I need to maintain four pieces of state for each texel: the current calculated "x", the current calculated "y", the iteration count, and whether the point is "done." Ideally I'd use floats for "x" and "y", a uint for "iterations", and a boolean for "done." SurfaceFormat.Vector4 would have been sufficient (albeit a bit wasteful), but the Xbox doesn't support it. I decided to use three SurfaceFormat.Single textures, and encode "done" into the iterations count by negating the value if the texel is done.

I had never tried using multiple render targets (MRT) before, but it worked fine. Instead of having the pixel shader output a float4, it needs to output a structure with values for each render target:

    float4 colorData = tex2D(dataSamp, pos);
    float4 colorData1 = tex2D(dataSamp1, pos);
    float4 colorData2 = tex2D(dataSamp2, pos);
    float x = colorData.r;
    float y = colorData1.r;
    float iterations = colorData2.r;
    bool done = false;
    if( iterations < 0 )
    {
        done = true;
        iterations = -iterations;
    }

    (Not shown here: update x, y, iterations, done)

    if( done )
        iterations = -iterations; 
    PS_OUTPUT output;
    output.x = float4(x,0,0,0);
    output.y = float4(y,0,0,0);
    output.iterations = float4(iterations,0,0,0);
    return output;

Wendybrot_2_0.zip