I’ve done my first releases of 2020 of my various GitHub projects, and there’s a number of changes worth mentioning. This includes updates to DirectX Tool Kit for both DX11 and DX12, DirectXTex, DirectXMesh, and UVAtlas, as well as a number of changes to my NuGet packages in particular.
VS 2015 Retirement
First up, I’ve retired all the VS 2015 projects for my GitHub projects. I’ve been maintaining VS 2015 Update 3, VS 2017, and VS 2019 for a while but for this year I’ve trimmed it back to just two versions again. There are a number of technical reasons for this, but the Windows 10 SDK itself hasn’t officially supported VS 2015 since the Creators Update (15063) back in March 2017. Hopefully this won’t be a problem for users of the libraries.
As a consequence, I’ve deprecated the following NuGet packages: directxtk_desktop_2015, directxtk12_desktop_2015, directxtex_desktop_2015, directxmesh_desktop_2015, and fx11_desktop_2015. VS 2017 and VS 2019 projects that use one of these packages should uninstall them and replace it with the new package: directxtk_desktop_2017, directxtk12_desktop_2017, directxtex_desktop_2017, directxmesh_desktop_2017, and fx11_desktop_2017.
Note I also now have a UVAtlas NuGet package: uvatlas_desktop_2017.
ARM64 Desktop Support
The Universal Windows Platform (UWP) app platform has supported ARM and ARM64 for a while, and I support those platform configurations in my UWP projects and NuGet packages: directxtk_uwp, directxtk12_uwp, directxtex_uwp, and directxmesh_uwp.
What’s new is that ARM64 Win32 desktop development is now supported, primarily to provide optimized applications for devices like the Surface Pro X. The following NuGet packages include ARM64 platform “desktop” configurations: directxtk_desktop_win10, directxtk12_desktop_2017, directxtex_desktop_win10, and directxmesh_desktop_win10.
DirectXMath has supported ARM64 for a numbers of years as noted in this blog post. This works ‘as is’ for UWP and ARM64 desktop apps.
DirectX Tool Kit for Audio
Per this post, there’s no compelling reason to keep using the legacy DirectX SDK any more thanks to the release of the XAudio2Redist NuGet package that provides a down-level version of XAudio 2.9 for Windows 7 SP1 and Windows 8.x, and uses the built-in version for Windows 10 automatically. I’ve updated DirectX Tool Kit for Audio to support building against the new Redist version which greatly simplifies XAudio2 usage on Windows 7 SP1 as well as providing xWMA support on Windows 8.x. The result is the same XAudio 2.9 API on Windows 10 (with a few minor caveats) on all these platforms.
The directxtk_desktop_2017 NuGet package has a dependency on XAudio2Redist. The GamePad input class uses XInput 9.1.0 to support Windows 7 SP1 without requiring the legacy DirectSetup REDIST, and the rest of the graphics components were already building for Windows 7 compatibility.
The directxtk_desktop_win10 and directxtk12_desktop_2017 NuGet packages are configured for Windows 10 only, so they use the built-in XAudio 2.9. Therefore they do not require
Microsoft.XAudio2.Redist, and neither do the UWP app packages
I’ve kept the XAudio 2.7 legacy DirectX SDK support in place in the GitHub repo, but I expect to retire it fully at some point later in the year.
Thanks to a community contribution, I now have WaveFront OBJ export support for DirectXMesh’s
uvatlastool.exe. These tools already read input from WaveFront OBJ but only produced
VBO; but now they also offer
OBJ. It’s a very basic format, but easy to read and well-understood.
Inspired by the CMake and clang/LLVM support added to Visual Studio 2019, I’ve authored
CMakeLists.txtfor all my libraries and tools, and validate code using Visual C++ as well as clang for Windows v9. I’ve worked to make all my projects build with
/Wallwhich for clang is really damn verbose to help ensure a high level of C++ conformance. I don’t personally put time into getting them to build for non-Windows platforms, but this should make it easier for other projects to do so if there is a desire for it.
The various tools like
texconv.exeetc. for my latest GitHub releases are now all digitally signed and versioned.
If you look at the wiki pages for my GitHub projects, you may notice a bunch of new shields for the GitHub repos, NuGet packages, and builds. There are now nightly builds pipelines hosted on Azure DevOps for both the primary library repos and the auxiliary test repos. I’ve been building the tests adhoc for many years, but put some time in to automate them.
I finally got around to converting all my Readme files for my GitHub projects from text files to Markdown
README.md. I’ve split out the complete release histories into their own