DirectXTK Update

The DirectX Toolkit (aka DirectXTK) for Direct3D 11 introduced last year and made an official CodePlex project has continued to improve. The DirectXTK project provides 'runtime' utility shared-source C++ code to replace the deprecated D3DX library for Win32 desktop applications using Direct3D 11 (Windows 8, Windows 7, Windows Vista SP2+KB971644, and the Server equivalents) as well as Windows Store apps on Windows 8. This complements DirectXTex which provides shared-source C++ code for 'build time' texture processing that used to ship in D3DX, DirectXMath and Spherical Harmonics math which replace D3DXMath, and the D3DCompile API which replaced the once integrated HLSL compiler. For Win32 desktop applications, there's also an Effects 11 to replace the FX library from D3DX9.

The original toolkit consisted of some key functionality based on the XNA Game Studio design: SpriteBatch, Effects, GeometricPrimitive along with some helper code (CommonStates, VertexTypes) and runtime texture loaders (DDSTextureLoader and WICTextureLoader). Shawn then added SpriteFont and support for Windows phone 8, and I added the ScreenGrab module to support the runtime creation of 'screenshots' from render targets. A fellow Microsoftie also contributed code for a geodesic sphereGeometricPrimitive as an alternative to the traditional UV-sphere.

The most recent additions to the library include

PrimitiveBatch - simple and efficient way to draw dynamic geometry as a replacement for the Direct3D 9 "DrawUP" and "DrawIndexedUP" functions, ideal for debug geometry or on-the-fly procedural geometry generation.

Improved GeometricPrimitive with support for proper winding order for both right-handed coordinates (the assumed default based on the XNA Game Studio conventions) and left-handed coordinates (typically used by DirectX C++ applications), as well as support for drawing them with custom effects.

Model - This draws simple meshes loaded from Visual Studio 2012's built in Autodesk FBX exporter .CMO files or the legacy DirectX SDK Samples Content Exporter.SDKMESH files. This is currently limited to rigid models but we'll be working to add skinning support.

The CodePlex site hosts the latest version of the library, documentation, discussion forums, bug reports, and feature requests. Developers can use Visual Studio 2012 or use Visual Studio 2010 with the standalone Windows 8.0 SDK.

The original email was communicating the phasing out of the specific "XNA Game Studio / DirectX SDK" MVP award expertise area. That's it.

The blog post went on to express Promit's feelings about how Microsoft has handled communication of 'prerelease' information with the MVPs over the past few years, and that is certainly his perspective to share if he chooses. Some product teams are very open with their plans (as was the case with XNA Game Studio and the Windows phone 7 teams), others are less (Windows 8, Xbox, etc.).

"DirectX" has been part of Windows for a long time now (over 8 years), and not a standalone platform. This is not news. As such, future roadmap information about DirectX is tied up with the future roadmap for Windows, Xbox, and Windows phone.

What I can say is that Direct3D 11 is essential to Windows Store apps and Windows phone 8. OpenGL is not an option for either platform. Direct3D 9 is essential to Xbox 360. XAudio2 is on all three platforms. XInput is on Windows and Xbox 360. Direct2D is essential to Windows Store apps.

The status for the whole family of DirectX APIs over the years is pretty well covered here.

I'm trying to develop an application that will support both Windows 8 Desktop and Windows Store, and I have a basic question on how to organize the files.

When developing for both these platforms, is it possible (if so, is it advisable) to combine the two deployment targets into a single solution file, with two projects (desktop and store) both including the same third project (static library)?

What's confusing is that there seems to be a distinction between "Windows Store Static Library" and "Win32 Static Library", and the two separate samples you provide appear to corroborate with this distinction.

It may be related that when I attempted linking the Windows Store project to my "Win32" shared library, it did seem to work for trivial operations, but upon inclusion of ppltasks.h the project would suffer linker errors.

I would recommend that your 'EXE' have a different project for the Windows Store vs. the Win32 desktop. You going to need a distinct project for the Windows Store that does all the building and creates the deployment, which is going to be very different than for the Win32 desktop. Anything dealing with UI, the main window loop, integration with the rest of the system is going to have to be different for those two app styles anyhow.

When it comes to the 'shared' code, a static library that does not make use of any WinRT calls could be made either 'type', or you can make it a Win32 DLL that only uses the 'safe' subset of APIs so it will pass the WACK tool. You do not have to use "/ZW" to compile a static library for use in a Windows Store app (i.e. if you don't use C++/CX language extensions which you don't need if not calling WinRT APIs). You do need to make sure that all the API calls in that library are only those in the WINAPI_FAMILY=WINAPI_PARTITION_APP and with _WIN32_WINNT=0x0602.

The more challenging issue is that if you want to support 'down-level' with your Win32 desktop app (which honestly makes a lot more sense than writing both a Windows Store app and a Windows 8 only Win32 desktop app), you have to have two different builds since you need to use different APIs depending on the _WIN32_WINNT setting and the like. You certainly can set up a single project with multiple configurations to achieve this, but you'll need to do a lot of the configuration manually (i.e. there isn't going to be any template in VS that does both Windows Store apps and Win32 desktops in the same project).

In a Windows Store project, there is a global project setting that affects all configurations: <AppContainerApplication>true</AppContainerApplication>. That triggers a lot of stuff which may be hard to replicate, but if you take the time to examine the build logs you can probably work it out.

This is one of the reasons why for DirectXTK we have distinct projects for Windows Store vs. Windows Desktop. Mixing both kinds of projects in the same solution is possible, but finicky.

Hi I have been working on extracting D3D11 initializing code from DXUT along with SettingsDlg which required me to port DXUTGUI in the process. Its almost done but can't find my around this error – WINCODEC_ERR_COMPONENTNOTFOUND when calling CreateWICTextureFromMemory.

I am trying to load that DXUTGUITextureSrcData texture that's harcoded in DXUTres.cpp