The DirectXTex library does an excellent job of providing all the ‘texture content processing’ functionality from the venerable D3DX library (see “Where is the DirectX SDK?“), and DirectXMath (or the older XNAMath) takes over for D3DXMath. Shawn Hargreaves and I have been putting together another utility library, dubbed “DirectX Tool Kit” or “DirectXTK”, to address some additional runtime needs for Direct3D 11 applications.

DirectXTK includes the following components: 

  • SpriteBatch – a 2D sprite rendering class (a C++ version of the SpriteBatch used for XNA Game Studio)
  • SpriteFont – a bitmap based text rendering (a C++ version of the SpriteFont used for XNA Game Studio)
  • Effects – a collection of ready-to-use common shaders (C++ versions of the BasicEffect, AlphaTestEffect, DualTextureEffect, EnvironmentMapEffect, and SkinnedEffect used for XNA Game Studio)
  • PrimtiveBatch – simple and efficient way to draw user primitives which replicates the simplicity of the Direct3D 9 era DrawUP APIs
  • GeometricPrimitives – geometry helpers for common shapes (Cube, Sphere, GeoSphere, Cylinder, Torus, Teapot, Tetrahedron, Octahedron, Dodecahedron, and Isosahedron)
  • Model – draws simple meshes loaded from .CMO or .SDKMESH files
  • CommonStates – Factory for common combinations of rendering states as Direct3D 11 state objects (C++ versions modelled after the ‘public fields’ of BlendState, DepthStencilState, RasterizerState, and SampleState classes used for XNA Game Studio)
  • VertexTypes –  collection of commonly used vertex buffer data structures with a input layout descriptions (C++ versions of VertexPositionColor, VertexPositionTextureVertexPositionColorTexture, and VertexPositionNormalTexture structures used for XNA Game Studio)
  • It also includes DDSTextureLoader,  WICTextureLoader, and ScreenGrab from the DirectXTex package.
  • SimpleMath – a wrapper for DirectXMath that makes it easier to write basic math operations without as many restrictions as the SIMD-friendly base library
  • And the MakeSpriteFont utility for generating .spritefont files (based on the Bitmap Font Maker Tool for XNA Game Studio)

Platforms: The code is designed to build with the Windows 8.x SDK using Visual Studio 2010, 2012, or 2013 and works on Windows Vista, Windows 7, Windows 8.x Win32 desktop, Windows Store apps, Windows phone 8.1, and Xbox One.

The README.TXT in the ZIP package contains additional information, and see Shawn’s posts here and here with some code snippets for usage.

Porting Notes

Here’s a handy table of equivalents for D3DX (see Living without D3DX for a complete listing):




SpriteFont, SpriteBatch


Model, ModelMesh, ModelMeshPart













Where XXX is “DDS” for working with .DDS files, or “WIC” for working with WIC-supported bitmap image formats such as .BMP, .JPG, .PNG, etc. Note that .TGA is supported by legacy D3DX and by DirectXTex, but not by DirectXTK.


Update: DirectXTK is now hosted on Codeplex and GitHub.The latest version of the library, documentation, notes on future work, release history, and other information is now available there. The library now includes PrimitiveBatch, ModelGamePad, and DirectXTK for Audio as well.

Windows phone 8: DirectXTK supports Windows phone 8 apps using the Windows phone SDK 8.0. See ShawnHar’s post. It also supports Windows phone 8.1 using VS 2013 Update 2 or later.

Related: DirectXMesh

Comments (13)

  1. MikeBMcL says:

    This is great!

    Just a quick note: the link to the Ms-PL in readme.txt doesn't work. I think you guys meant it to be this instead:…/licenses.aspx .

  2. SleepyDaddySoftware says:

    I haven't had time to look at it, but it sounds great. One minor thing (and maybe you have something like this already) – it would be great if some of the functionality that was moved from XNA (like SpriteBatch) had WinRT component-izeable versions of those classes (maybe using a preprocessor switch so you can use this library outside of WinRT too) so that we can have easier managed code interop with it. Would make it easier to port exisitng XNA games if we could have a C++ shell as the base using DirectXTK (handling setup, shutdown, and resources) with managed C# code on top with our existing game logic. This C# code could then directly interact with the now-native SpriteBatch and other APIs as WinRT components.

  3. Nate says:

    This is awesome!  Any chance you will make a WinRT Component project wrapping this and exposing it to C# developers?

  4. XNA Dev says:

    Since all my games are written in XNA and C# I think it would actually be easier to port them over to Xaml + C#.

    1. long says:

      well,i want to know if there have a directxkt for c#

      1. MonoGame or Unity is your best bet.

        1. zhang says:

          thanks ,and i want to wirte a sdkmesh model ,but i know noting ,if you have some idea? haha,if you understand me。。。

          1. For a simple Wavefront OBJ file, you can use the meshconvert tool from DirectXMesh. I cover this in the DirectX Tool Kit model tutorial. Otherwise, you can use the full DirectX Samples Content Exporter that reads from Autodesk FBX files.

  5. asdbsd says:

    Any chance MS will release a source code for ID3DXFont now that everything's deprecated anyway? I'm trying to reimplement it but it's tough to guess how exactly it does what it does. Just creating a texture and byte-copying letters to it does not give the same quality when the output is scaled. Mipmaps don't help either.

  6. Is there some reason why you can't just recreate the font with DirectXTK's SpriteFont instead of having to try to use ID3DXFont data?

  7. asdbsd says:

    It's a text-heavy application, and I need to support unicode (CJK) as well as color and bold, italic effects where applicable. DirectWrite seems to be the way to go, but I have to be backward-compatible with XP. I thought I'd just render with GDI and output to texture, similar to how D3DXFont does.

  8. If you need to be compatible with Windows XP, keep using D3DX. You aren't likely to find a newer solution that supports Windows XP.

  9. asdbsd says:

    That's the problem. D3DXFont just can't handle the walls of text I sometimes have. I figured it's because it always prints the text letter by letter, and if I pre-rendered the whole paragraph into a texture it'd be much faster. And it is, but the quality of text is much worse when scaled. After studying it a bit with PIX, it seems D3DXFont generates mipmaps for its letter texture, and I can't figure out the algorithm behind making those. It's not 2×2 block average, that's for sure. Something like sqrt(a^2 + b^2 +c^2 + d^2)/2, but not quite, and it still doesn't give me decent quality when I do it myself.

    Maybe the trick is in how D3DXFont renders those letters… the texture is all black, only alpha-channel contains characters as 0xFFs on transparent. Anyway, it's hard to guess.