Quantcast
Channel: Games for Windows and the DirectX SDK
Viewing all 44 articles
Browse latest View live

Getting Started with Direct3D 12

$
0
0

The first thing to do is get up to speed on Direct3D 11 (see Getting Started with Direct3D 11), especially if you are coming from a background of knowing Direct3D 9. Jumping feet-first into Direct3D 12 without a solid grounding in what a Direct3D feature level means, DXGI device-and-swapchain creation, the modern HLSL compiler story, the fate of the legacy DirectX SDK, and the Direct3D 10/Direct3D 11 state model and graphics pipeline design is a recipe for confusion and frustration.

DirectX 12 is an expert API which builds on knowing the ins & outs of DirectX 11. DirectX 12 is an extremely low-level API designed for graphic experts who have a solid understanding of the architecture of modern GPU hardware, and can essentially write the DirectX 11 Runtime from scratch. Both DirectX 11 and DirectX 12 provide access to the same hardware features on Windows 10, but drive the hardware in different ways which can allow a well-optimized DirectX 12 engine to achieve much lower CPU overhead than in DirectX 11.

With that preamble out of the way, you should familiarize yourself with the documentation on MSDN and the official samples on GitHub. Then install Visual Studio 2015 and be sure to install the Windows Tools and Windows 10 SDK component. See this blog post for details.

For introductory samples, take a look at D3D12HelloWorld (PC desktop and UWP), as well as the Xbox ATG Graphics UWP samples. DirectX Tool Kit for DirectX 12 includes some tutorials as well.

Presentations: There’ve been a number of public presentations on Direct3D 12.

DirectX: Evolving Microsoft’s Graphics Platform (GDC 2014): link

Direct3D 12 API Preview (BUILD 2014): link

Better Power, Better Performance: Your Game on DirectX12 (GDC 2015): link

Advanced DirectX12 Graphics and Performance (GDC 2015/BUILD 2015): link

Direct3D Update: (GDC 2016): link

There is also a series of YouTube videos on various aspects of Direct3D 12 you should take a look at as well.

AMD, Intel, and NVidia also have additional materials available online.

Debugging: The debug device (aka the Developer Runtime) on Windows 10 is not installed by any SDK. It is enabled as a Windows Optional Feature called “Graphics Tools”. See this post for details. You should also familiarize yourself with DXGI debugging features.

Utilities: The various Direct3D 12 templates make use of a simple header-only helper D3DX12. This does not have nearly the scope of the deprecated D3DX libraries, but is useful in taking care of many of the more mundane aspects of creating the required structures. For support in loading textures, rendering fonts & sprites, loading models, etc. see DirectX Tool Kit for DirectX 12. For graphics math, see DirectXMath. You should use DirectXTex, DirectXMesh, and UVAtlas for content processing as well.

Multi-GPU: See this blog post.

Related: Anatomy of Direct3D 12 Create Device, Direct3D Game Visual Studio templates (Redux), Windows 10 Anniversary Update SDK


DirectXTex and DirectXMesh now support Direct3D 12

$
0
0

As part of my multi-year personal project of providing open source replacements for the deprecated D3DX library once found in the legacy DirectX SDK, two libraries are focused on content creation tools and build pipelines. DirectXTex handles loading image files, texture processing including format conversion, mipmap generation, block-compression, and writing out ‘fully cooked’ textures into DDS files. DirectXMesh provides geometry support such as computing normals and tangent-frames, transparent vertex cache optimization, and provides utilities for extracting/inserting vertex data in vertex buffers.

These libraries were originally written for DirectX 11, and it seems likely that most tools should continue to use DirectX 11 for the simplicity and ease of developer productivity. There are, however, cases where you want to use some of this functionality ‘in-engine’, so the January 2017 releases include DirectX 12 API support as well.

DirectXTex January 2017 release on GitHub

DirectXMesh January 2017 release on GitHub

To simplify supporting all the various platforms and Windows SDK combinations, the library continues to default to using DirectX 11. If you want to use DirectX 12, you need to explicitly include the required headers before including the library header:

#include <d3d12.h>
#include "DirectXTex.h"

You also need to link with the DirectXTex_Desktop_2015_Win10.vcxproj, DirectXTex_Windows10.vcxproj, or DirectXTex_XboxOneXDK_2015.vcxproj projects which build with both DirectX 11 and DirectX 12 support.

If you want to use both DirectX 11 and DirectX 12 in the same compilation module, then you need to explicitly include both:

#include <d3d11_1.h>
#include <d3d12.h>
#include "DirectXTex.h"

The story is similar for DirectXMesh, although in this case it’s just to let you use D3D12_ input layouts enums and structures instead of D3D11_–the data itself is identical.

In case you missed it, DirectXTex was updated to support the HDR (RGBE) file format as a source for floating-point HDR texture data, as well as having ‘opt-in’ support for OpenEXR. For more details on how to enable OpenEXR, see this page.

Related: DirectX Tool Kit for DirectX 12

DirectX Tool Kit and C++/WinRT

$
0
0

The February 2017 releases of DirectX Tool Kit for DirectX 11 and DirectX 12 are now available on GitHub. In addition to various bug-fixes and a few minor improvements to the input classes (Mouse, Keyboard, and GamePad), the libraries now also support C++/WinRT applications for UWP and Xbox One. C++/WinRT language projections allow you to use Windows Runtime APIs without using the C++/CX language extensions (i.e. the libraries will work with applications built with or without /ZW).

For more on C++/WinRT, see:

https://moderncpp.com/

C++ – Introducing C++/WinRT (MSDN Magazine)

cppwinrt on GitHub

Migrating C++/CX source code to C++/WinRT

Embracing Standard C++ for the Windows Runtime” (CppCon 2016)

Putting Coroutines to Work with the Windows Runtime” (CppCon 2016)

VS Templates: I’ve added C++/WinRT variants of my Direct3D UWP templates for DirectX 11 and DirectX 12 to directx-vs-templates and the VS 2015 VSIX.

NuGet: You can use  C++/WinRT on NuGet as an easy way to add the C++/WinRT headers for the Windows 10 Anniversary Update (14393) to the templates above or your own project.

Compiler: To use C++/WinRT, you must be use using Visual Studio 2015 Update 3 or Visual Studio 2017 and build with the /std:c++latest switch. The use of /await is also recommended.

DirectXMath, DirectXTex, DirectXMesh: These libraries are also compatible with both C++/WinRT and C++/CX applications.

Related: DirectX Tool Kit for DirectX 12, Direct3D Game Visual Studio templates (Redux)

Visual Studio 2017

$
0
0

Visual Studio 2017 RTM is now available for download, including the updated Community edition. The VS 2017 RTM Redistribution packages are also available (x86, x64), as well as the Remote Debugging Tools (x86, x64). For more information see the Visual C++ Team Blog and Visual Studio Team Blog.

This version of Visual Studio includes a new lightweight installer. Be sure to read this post for an overview. Note that most C++ workloads include the Windows 10 Anniversary Update SDK (14393) by default, but older versions including Windows 8.1 SDK are available as optional components.

The latest docs are located here rather than their traditional location on MSDN.  In particular, see the Visual C++ Porting and Upgrading Guide.

UWP C++ Developers:  When you select the Universal Windows Platform (UWP) workload, be sure to add the optional component C++ Universal Windows Platform tools.

Automated Installs: See this page for details on installing VS 2017 from the command-line. For example, this installs C++ toolsets for game development for Win32 classic desktop and UWP apps:

vs_community.exe --lang en-us --add Microsoft.VisualStudio.Workload.NativeGame
--add Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Win81
--add Microsoft.VisualStudio.Workload.Universal
--add Microsoft.VisualStudio.ComponentGroup.UWP.VC
--add Microsoft.VisualStudio.Workload.NativeDesktop --includeRecommended -p --wait

Compiler and CRT

VS 2017 includes a new version of C/C++ compiler (19.10.25017). See this blog post and this post for details on the new compiler and standards conformance (including more work on Expression SFINAE and additional C++14 conformance). See this post for details on /analyze updates, and this post for details on the C++ Core Guidelines Checker.

The C/C++ Runtime (4.10.25008) is binary compatible with VS 2015, which means you can safely link code built with VS 2015 with VS 2017 applications. See this post and this post for details. For details on library fixes in the latest version, see this post.

VS 2017 can target Windows 10, Windows 8.1, Windows 7 Service Pack 1, Windows Vista Service Pack 2, and optionally Windows XP Service Pack 3. Note that the Visual C++ 2017 REDIST does not support Windows 8.0, Windows 7 RTM, Windows Vista RTM, Windows Vista Service Pack 1, Windows XP RTM, Windows XP Service Pack 1, or Windows XP Service Pack 2 as these platforms are all outside their support lifecycle. See Visual Studio 2017 Product Family System Requirements.

Visual ++ Build Tools 2017: There’s an edition of Visual Studio available without the IDE for those looking for just the compiler toolset or setting up a build server.

Known issues

  • Note that there are errors generated when using the new VS 2017 conformance switch with the platform headers in Windows 10 SDK (14393) or earlier. These are addressed in the upcoming Windows 10 Creators Update SDK. Microsoft Developer Insiders can try out /permissive- with the preview SDK.
  • When you upgrade a project to the v141 toolset, you are given a UI prompt to select which version of the Windows SDK to use based on all the side-by-side installed SDKs.  This is ignored for Win32 desktop projects. To use a newer Windows SDK, you should edit the project properties after the upgrade–otherwise it’s likely the 8.1 SDK will be required, which is not installed by default.

Windows XP: When building using the “v141_xp” Platform Toolset for Windows XP Service Pack 3 target support, remember this uses the Windows 7.1A SDK. The older SDK will generate some warnings in system headers with the new toolset that have to be externally suppressed. See VS 2012 Update 1 for some additional implications for DirectX development.

DirectX SDK: If you need to continue to make use of legacy DirectX SDK components such as D3DX9, D3DX10, D3DX11, or XAudio 2.7 with Visual Studio 2017, see MSDN for details on mixing the paths correctly. See also DirectX SDKs of a certain age, The Zombie DirectX SDK, Living without D3DX, DirectX SDK Tools Catalog, DirectX SDK Samples Catalog, and Where’s DXERR.LIB?

GitHub: There are VS 2017 projects in the latest releases of DirectX Tool Kit for DirectX 11, DirectX Tool Kit for DirectX 12, DirectXTex, DirectXMesh, UVAtlas, DXUT, and Effects 11. These are set up to use the Windows 10 SDK (14393) because that’s the default version for VS 2017. Because of the fact that VS 2015 and VS 2017 are binary compatible w.r.t. to the C/C++ runtime, you can use the 2015 version of the NuGet packages with VS 2017. The Direct3D Game templates have been updated to support VS 2017 as well, and the Direct3DUWPGame.vsix now supports both VS 2015 aad VS 2017.

Windows 10 Creators Update SDK

$
0
0

The Windows 10 Creators Update (build 15063, aka Version 1703) is now available along with a new Windows 10 SDK release. The Windows 10 Creators Update SDK (10.0.15063) can be installed via VS 2017 or as a standalone installer. This includes DirectXMath 3.10 and updated versions of Direct3D 12, Direct3D 11.4 Direct2D, and DirectWrite.

VS 2015 Users: Note that the Windows 10 SDK (15063) is officially only supported for VS 2017.

VS 2017 Users: The Windows 10 Creators Update SDK resolves a number of conformance errors in Windows system headers enabling the use of the /permissive- switch.

Related: Windows 10 SDK RTM, Windows 10 SDK (November 2015), Windows 10 Anniversary Update SDK

DirectXMath 3.10

$
0
0

DirectXMath version 3.10 is included in the Windows 10 Creators Update SDK (15063) which is installed with Visual Studio 2017.

The new version includes the following:

  • Added XMVectorSum for horizontal adds
  • ARMv8 intrinsics use for ARM64 platform (division, rounding, half-precision conversion)
  • Added SSE3 codepaths using opt-in _XM_SSE3_INTRINSICS_
  • XMVectorRound fix for no-intrinsics to match round-to-nearest (even)
  • XMStoreFloat3SE fix when max channel isn’t a perfect power of 2
  • constexpr conformance fix and workaround for compiler bug in VS 2015 RTM
  • Remove support for VS 2012 compilers
  • Remove __vector4i deprecated type

SSE3

For the Windows x86 and Windows x64 platforms, the DirectXMath library assumes you are using SSE/SSE2 as support for those is required by the platform (see this blog post for details). If you use the /arch switch with AVX or AVX2, it makes use of additional instruction sets including SSE3, SSE4.1, AVX, and F16C. Previously you could enable the SSE 4.1/SSE3 optimizations together, but now with DirectXMath 3.10, the SSE3 optimizations can be enabled independently. Officially SSE3 is not required by the base Windows platform, but it’s support is very wide-spread so you can choose to require SSE3 even without requiring SSE4.1 or AVX/AVX2. See this blog post.

NuGet

This version can also be obtained via NuGet which will work with Visual Studio 2013 and Visual Studio 2015. DirectXMath no longer supports VS 2012.

GitHub

In addition to shipping with the Windows SDK and the Xbox One XDK, DirectXMath is also available on GitHub under the MIT license.

Related: Known Issues: DirectXMath 3.03, DirectXMath 3.06, DirectXMath 3.07, DirectXMath 3.08, DirectXMath 3.09

A look back: Windows Vista

$
0
0

This is a bit of a nostalgic navel-gazing like my Windows XP post was back in October 2010, so please forgive my indulgence.

This week, Windows Vista has officially reached end-of-life. There’s been a few retrospective press pieces like this one on Ars Technica, so I thought I’d chime in with my own thoughts. I started my tenure at Microsoft the week that Windows XP Service Pack 2 shipped, so I missed much of the early over-promising of “Project Longhorn” as well as the grueling grind of the “security reset” that culminated in the Windows XP SP2 release, so I consider Windows Vista to really be my ‘first Windows release’. There was a lot of game developer education needed for Windows Vista including Direct3D 10, Game Explorer, Parental Controls, User Account Control, and Windows x64–my first public presentation on Windows Vista was back at GDC 2006.

While the RTM of Windows Vista was indeed a rough experience all around, by the time Service Pack 1 shipped things were in pretty good shape technically. This was particularly true with all the catch-up work done by 3rd party drivers that weren’t ready by original ship. The reputational issues lingered, deserved or not, but for gamers on Windows, the Windows Vista release did a lot of good which made Windows 7 and later versions of the OS better.

  • Direct3D was an essential technology for Windows instead of kind of a bolt-on thing only used by games. The WDDM driver model really drove support and stability, and Direct3D 10 set the stage for Direct3D 11 and Direct3D 12 in a big way.
  • Windows Vista made 64-bit (x64) a thing. Windows XP x64 Edition was definitely an ‘early-adopter’ OS with a lot of quirks and never had much in the way of driver or application support, but Windows Vista made x64 a broad-based consumer scenario. The decision to include both x86 and x64 media at retail was a big part of that, and with gamer machines shipping with 4 GB or more physical RAM it was desperately needed–see this article.
  • Getting games to run as Standard User instead of assuming always-on administrator rights was the right thing for security generally, but was a real slog to make happen. There was also a push to get more game publishers to code sign their binaries which started to get traction with Windows Vista.

So if you love Windows 7 or Windows 10, remember to pour one out for the unloved older sibling that paved the way with a lot of blood, sweat, toil, and tears…

DirectXMath 3.11

$
0
0

DirectXMath version 3.11 is now available on NuGet and GitHub. It will be included in the upcoming Windows 10 Fall Creators Update SDK (currently in Preview build 16225 or later) and the Xbox One XDK (June 2017).

  • AVX optimization of XMMatrixMultiply and XMMatrixMultiplyTranspose
  • AVX2 optimization for XMVectorSplatX
  • FMA3 optimization of XMVectorMultiplyAdd and XMVectorNegativeMultiplySubtract
  • Conformance fixes to support compilation with Clang 3.7

The main addition for this version are the control defines for _XM_AVX2_INTRINSICS_ and _XM_FMA3_INTRINSICS_, both of which are enabled when using /arch:AVX2 along with the already existing _XM_F16C_INTRINSICS_. For details on the few AVX2 optimizations applicable to DirectXMath see this blog post, and for FMA3 see this post. This means that when you build using /arch:AVX2, the XMVerifyCPUSupport function will explicitly check for AVX2, FMA3, and F16C processor support.

Down the Conformance Rabbit Hole

For this release I did a fair amount of syntax cleanup for better C++11/C++14 conformance by getting the headers to build without warnings when using the Clang 3.7 compiler with Microsoft codegen. I can’t speak to the quality or correctness of the generated code, but I wanted to make sure the source code was as conforming as I could make it–VS 2017’s /permissive- standard enforcement switch helps, but there’s no substitute for trying to build with a different compiler toolset.

A basic issue is that intrinsics themselves are implementation dependent, and in particular the way that the type __m128 is defined is not consistent between Visual C++ and Clang. Visual C++ treats it as a union, while Clang considers it a special opaque type. Therefore, I had to modify all places where the members of the __m128 union were being manipulated. This is pretty easy because I already have portable unions that work: XMVECTORF32, XVMECTORU32, and XMVECTORI32.

A knock-on impact of the way the __m128 type is defined means that you can overload free functions based on it with Visual C++, but you cannot do so with Clang. In other words, this is legal C++ with Visual C++ but not when using Clang:

__m128 operator+(__m128 V);

Rather than break existing users of these overloads on Visual C++, I guard their definition with a new control define, _XM_NO_XMVECTOR_OVERLOADS_, which I automatically enable when building with Clang. This also meant updating all the places in the other DirectXMath implementation headers where I relied on the overloads to use explicit functions instead. Note that there’s no equivalent issue with XMMATRIX overloads because this is itself a struct.

The bulk of the remaining conformance changes were fully bracing the initialization of XMVECTORF32 and related types:

static const XMVECTORF32 c_value = { 1.f, 2.f, 3.f, 4.f };

had to be changed to:

static const XMVECTORF32 c_value = { { { 1.f, 2.f, 3.f, 4.f } } };

It also turns out that the Clang compiler doesn’t like the trick used by the UNREFERENCED_PARAMETER macro. Instead of having:

XMVECTOR Permute(FXMVECTOR v1, FXMVECTOR v2) { (v2); return XM_PERMUTE_PS(v1, Shuffle); }

The name of the unreferenced formal parameter has to be removed to make both compilers happy:

XMVECTOR Permute(FXMVECTOR v1, FXMVECTOR) { return XM_PERMUTE_PS(v1, Shuffle); }

I also added guards to #pragma prefast statements which Clang complains about (although it ignores other common #pragma statements such as #pragma warning)

Related: Known Issues: DirectXMath 3.03, DirectXMath 3.06, DirectXMath 3.07, DirectXMath 3.08, DirectXMath 3.09, DirectXMath 3.10


HDR Lighting and Displays

$
0
0

High Dynamic Range (HDR) lighting has been used in games for a long time, popularized by titles like Valve's Half-Life 2 using DirectX 9.0c. The rendering uses float-point render targets, allowing the lighting to exceed the normal 0 to 1 range. Then the final result is tone-mapped back into normal range for display. The result is much improved contrast, making it easier to see a mix of dark interiors with bright exteriors, more realistic outdoor lighting, and a host of special effects.

Recent advances in display technology are adding the ability to render a wider range of luminance directly on the display, enabling a wider gamut of colors and better handling of HDR images and scenes. The 4k Ultra High Definition (4K UHD) standard includes the HDR10 Media Profile supported by game consoles like the Xbox One S and Xbox One X, as well as by Windows PCs running the Windows 10 Creators Update. A range of HDR10 capable TVs and monitors are becoming available.

DeviceResources

The DeviceResources abstraction (DX11 and DX12) used in directx-vs-templates and Xbox-ATG-Samples now supports an options flag for HDR10 display output. To enable this support, you must build the code using the Windows 10 Creators Update SDK (15063) which also implies that you are using VS 2017--the Windows 10 SDK (15063) doesn't officially support use with VS 2015. The code will run on older versions of Windows, but you can only get HDR10 output if running on a PC with the Windows 10 Creators Update as well as the required video card, driver, and display combination.

Note the latest DeviceResources will build with VS 2015 and/or the Windows 10 Anniversary Update SDK (14393), but won't be able to detect HDR10 display output.

DirectX Tool Kit

In order to render an HDR10 swapchain on PC, UWP, and Xbox One, a postprocessing step is typically required to rotate the color space appropriately. To simplify this, I've added a ToneMapEffect (along with other post-processing support) to DirectX Tool Kit (DX11 and DX12). The ToneMapEffect class supports preparing the HDR10 swapchain (rotating from Rec.709 to Rec.2020 color primaries, and applying the ST.2084 curve), as well as traditional tone-mapping for supporting classic Standard Dynamic Range (SDR) displays.

Details on how to use these classes are on the wiki (DX11 and DX12) and in the tutorials (DX11 and DX12).

I've also added HDR10 display support and tone-mapped SDR display support to the DirectX Tool Kit Model Viewer (DX11 and DX12).

DirectXTex

Note that last year I added support for the Radiance RGBE (.hdr) file format as a source for HDR textures to DirectXTex. The texconv and texassemble tools were updated to support .hdr at this time. I also added a -tonemap switch (using a Reinhard local operator) to the command-line tools to support conversions of HDR textures to SDR range for debugging and diagnostics.

In addition to .hdr file format support, I added instructions/support for opting in to support OpenEXR (.exr) as well. See Adding OpenEXR for more information. Thanks to some community efforts, this is now easier to do by obtaining the required OpenEXR and ZLib libraries from NuGet.

This support is also include in the latest DirectX SDK Sample Content Exporter.

Visual Studio 2017 (15.3) update

$
0
0

Since the release of Visual Studio 2017 in March, there have been two minor updates (15.1 and 15.2) per the new release rhythm. The first update (15.1) integrated the Windows 10 Creators Update SDK (15063), and the second update (15.2) included fixes for the IDE and tools. Neither of these updates included significant changes to the C/C++ compiler beyond a few specific hotfixes. The first major revision to the Visual C++ 19.1 compiler and libraries is now available with the latest update: Visual Studio 2017 (15.3).

If you already have VS 2017 installed, run the "Visual Studio Installer" application on your system to apply the update. If you don't yet have VS 2017 installed, you can download the latest installer from here.

The latest VS 2017 Redistribution packages are available (x86, x64), as well as the Remote Debugging Tools (x86, x64). For more on the Visual Studio 2017 (15.3) update, see the release notes.

Note:  The Lightweight Solution Load option that does a partial load of projects for large C++ solutions is included in this update.

Compiler and CRT

VS 2017 (15.3) inclues a new version of the C/C++ compiler (19.11.25506). See this blog post for details on the latest Standard conformance and language/library fixes. There are a few new warnings--a few of which are currently off-by-default but quite useful for portability--detailed in this blog post. The latest update also includes support for AVX-512 intrinsics.

Note: Per this blog post, the _MSC_VER value is now 1911 instead of 1910.

The C/C++ Runtime (14.11.25325) is included in this update. Remember that VS 2015 and VS 2017 share the same runtime redistributable binaries and that VS 2015 Update 3 is binary compatible with VS 2017--code or static library built with one can be linked to the other--, so this is the latest version for both.

The C++ Core Guidelines checker has also been updated. See this blog post as well as this one.

directx-vs-templates: The VS 2017 (15.3) includes a fix with my Direct3D game templates if using them on a system without VS 2015 installed side-by-side.

Related: Visual Studio 2017 RTM

Windows 10 Fall Creators Update SDK

$
0
0

The Windows 10 Fall Creators Update will be released October 17 is now available. The Windows 10 Fall Creators Update SDK (10.0.16299) is now available and can be installed via VS 2017 (15.4) or as a standalone installer. This includes DirectXMath 3.11, updated DirectX 12, and updated Direct2D/DirectWrite.

The Windows 10 Fall Creators Update SDK resolves a number of conformance errors in Windows system headers enabling the use of the /permissive- switch with the latest two-phase name lookup (thus allowing you to avoid the need to use /Zc:twoPhase-).

Note: See KB4034825 for some deprecation notes for the Windows 10 Fall Creators Update

C/C++ Compiler: The VS 2017 (15.4) compiler contains a few servicing updates since the previous update (version 19.11.25547).

C++/WinRT: New C++/WinRT headers for this Windows 10 SDK are now available on GitHub and NuGet.

FXC: With the Windows 10 SDK (15063/16299), the FXC compiler and the D3DCompiler_47.DLL were made side-by-side. From the Developer Command Prompt for VS 2017, using FXC will use the Windows 10 Anniversary Update (14393) version. You need to explicitly select the side-by-side version if you want to use a newer one from the command-line: "%WindowsSdkBinPath%%WindowsSDKVersion%\x86\fxc.exe"

GitHub: I've made new releases of my various libraries that now build with the Windows 10 SDK (16299): DirectX Tool Kit (DX11, DX12), DirectXTex, DirectXMesh, and UVAtlas.

Samples: Windows-universal-samples and DirectX-Graphics-Samples have been updated to use the new Windows 10 SDK (16299). There is also a new version of D3DX12.H updated for the updated Direct3D 12 headers (now included in directx-vs-templates)

Related: Windows 10 SDK RTM, Windows 10 SDK (November 2015), Windows 10 Anniversary Update SDK, Windows 10 Creators Update SDK

CodePlex vs. GitHub

$
0
0

Note that as of today, CodePlex is now 'read-only' per this blog post and this announcement. I've been recommending people using CodePlex for DirectX Tool Kit for DirectX 11, DirectXTex, DirectXMesh, and UVAtlas move to using GitHub for some time, but it's now official. The CodePlex archive is expected to stay online as read-only, but with respect to my projects the GitHub version is now the only repo and the CodePlex version is an outdated mirror.

DirectXMesh GitHub
CodePlex (read-only, last updated September 2017)
DirectXTex GitHub
CodePlex (read-only, last updated September 2017)
DirectXMath GitHub
DirectX Tool Kit (DX11) GitHub
CodePlex (read-only, last updated September 2017)
DirectX Tool Kit (DX12) GitHub
UVAtlas GitHub
CodePlex (read-only, last updated September 2017)
DXUT GitHub
CodePlex (read-only, last updated July 2017)
Effects 11 GitHub
CodePlex (read-only, last updated March 2017)

VS 2017 (15.5 update)

$
0
0

The Visual Studio 2017 (15.5 update) is now available for download, and you should see the 'new update available' notification in the coming weeks--you can also get the update now by downloading the 'free trial' version of the installer which will let you update your system. This is second major update to the 19.x C++ compiler with a focus on C++17 conformance and bug fixes.

The latest VS 2017 Redistribution packages are available (x86, x64), as well as the Remote Debugging Tools (x86, x64). For more on the Visual Studio 2017 (15.5) update, see the release notes.

Compiler and CRT

VS 2017 (15.5) includes a new version of the C/C++ complier (19.12.25830). See this blog post for details on the latest C++17 Standard conformance as well as MSDN.

The /permissive- switch can be specified with a new VC++ project element <ConformanceMode> instead of having to use <AdditionalOptions> starting with the 15.5 update. Newly created VC++ project templates after the 15.5 update will include this element by default except for those that have C++/CX (/ZW) enabled.

Note: Per this blog post, the _MSC_VER value is now 1912 instead of 1910 or 1911

Side-by-side compiler versions: The 15.5 update also supports selecting the older 15.4 compiler (which was basically the same as the 15.3 compiler with a fix hotfixes) with new side-by-side support. In the installer go to the Individual Components tab and check VC++ 2017 version 15.4 v14.11 toolset. This is intended for use in diagnosing potential compiler regressions should you encounter them as it's enabled via manually updating a specific .props file on your system.

std::function: If you make use of this aspect of the STL as I do in DirectX Tool Kit et al, you should read this blog post about some debugging improvements in 15.5.

The C/C++ Runtime (14.12.25810) is included in this update. Remember that VS 2015 and VS 2017 share the same runtime redistributable binaries and that VS 2015 Update 3 is binary compatible with VS 2017--code or static library built with one can be linked to the other--, so this is the latest version for both.

Related: Windows 10 Fall Creators Update SDK (15.4), VS 2017 (15.3 update)Windows 10 Creators Update SDK (15.1/15.2), Visual Studio 2017 (15.0)

DirectX and UWP on Xbox One

$
0
0

With the release of the Fall Creators Update (October 2017) for Xbox One, UWP apps can now opt into expanded resources as was announced in this Windows Blog post. Details about UWP on Xbox One can be found on MSDN, but in this blog post I’ll be talking about a few technical issues and specifics I encountered while updating the UWP samples on the Xbox-ATG-Samples GitHub and working with the UWP versions of my Direct3D Game template.

Game mode

By default all UWP apps run on the Xbox One (which must support either the “Universal” or “Xbox” device family and be built for the x64 architecture) run in a shared system mode with a subset of system resources with the remainder of the system resources reserved for games. With the latest version of the OS, a UWP app can declare itself a ‘Game’ which will give it access to additional memory, CPU, and GPU resources.

When an application is published, this is handled by Windows Store metadata that indicates it is a ‘Game’ rather than an ‘App’. During development, you manually set the package’s type to ‘Game’ via the DevHome interface.

First, build & deploy the application package to the Xbox One. Then using the Xbox One game controller, highlight the package in DevHome’s Games & apps list:

Then press the View button to bring up the context menu:

Go down to the bottom to View details and press the A button:

This brings up the App details page and the App type field should be selected. Use the combo box to set it to “Game” by pressing A, down on the D-pad, and then pressing A again. Then press B to return to the main page.

When you start the application, it will be running in Game mode.

Note that the “expandedResources” restricted capability in the Appx manifest still exists, but it’s use is deprecated. While I make use of it in some of the ATG samples to simplify deployment, any UWP submitted to the Windows Store will fail submission if it makes use of this restricted capability.

Note: You can also use the Xbox Device Portal (Windows Device Portal on Xbox) to configure your Xbox One to default to “Game” rather than “App” for newly deployed development apps as of the November 2017 update. If you change this setting, keep in mind that if you also want to develop a non-game application, you should explicitly set it to ‘App’ using the instructions above.

DirectX 11

For UWP on Xbox One, the DirectX 11 device is supported using Direct3D Feature Level 10.0. This is still true in Game mode, although you have significantly more GPU resources available to you than when you run as an ‘App’.

The default DirectX 11 device creation for a UWP app typically includes the 9.3 and later Direct3D feature levels:

D3D_FEATURE_LEVEL lvl[] =
{
    D3D_FEATURE_LEVEL_11_1,
    D3D_FEATURE_LEVEL_11_0,
    D3D_FEATURE_LEVEL_10_1,
    D3D_FEATURE_LEVEL_10_0,
    D3D_FEATURE_LEVEL_9_3
};

In practice Direct3D Hardware Feature Level 10.0 provides a significant set of capabilities suitable for many games:

Supported for DirectX 11 (UWP on Xbox One) Not supported
Shader Model 4.0 Shader Model 5

DirectCompute

Geometry Shader and Stream Out Tessellation/Hull Shaders
BC1/BC2/BC3/BC4/BC5 BC6H/BC7
1D, 2D, 3D Textures

1D and 2D Texture Arrays

Cubemaps

Cubemap arrays
Instancing, Alpha-to-coverage, Event queries MSAA texture per-sample shaders
8092 maximum texture size

Note that in development mode, if you try to create a DirectX 11 device and do not provide the option of using D3D_FEATURE_LEVEL_10_0, then you will end up with a WARP software device rather than the much faster hardware device. Remember also that WARP it not supported for retail Xbox One machines.

See Anatomy of Direct3D 11 Create Device for more details on DirectX 11 device creation.

DirectX 12

For UWP on Xbox One, DirectX12 is supported as Direct3D Hardware Feature Level 12.0 while in Game mode.

Note that in development mode, if you try to create a DirectX 12 device while not in Game mode, you will end up with a WARP software device rather than the much faster hardware device. Remember also that WARP it not supported for retail Xbox One machines.

See Anatomy of Direct3D 12 Create Device for more details on DirectX 12 device creation.

Game controller usage

If you are using the Direct3D app model for your game rather than XAML or Direct3D+XAML, an important thing to note is that you need to handle the BackRequested navigation event. This event is generated whenever the B button is pressed on the Xbox One game controller, and if not handled it will result in the application being suspended as control is returned to DevHome (or the previous app). Typically Direct3D games would use Windows.Gaming.Input (or the XINPUT emulator library xinput_uap.lib) to react directly to the use of the B button as appropriate to the game control scheme rather than rely on the notion of a ‘page stack’.

See also GamePad in the DirectX Tool Kit (DX11 / DX12).

C++/CX

If using C++/CX (a.k.a. /ZW) then you can implement this as follows:

virtual void SetWindow(CoreWindow^ window)
{
    ...
    auto navigation =
        Windows::UI::Core::SystemNavigationManager::GetForCurrentView();
    navigation->BackRequested +=
    ref new EventHandler<BackRequestedEventArgs^>(this,
        &ViewProvider::OnBackRequested);
}

void OnBackRequested(Platform::Object^,
    Windows::UI::Core::BackRequestedEventArgs^ args)
{
    // UWP on Xbox One triggers a back request whenever the B
    // button is pressed which can result in the app being
    // suspended if unhandled
    args->Handled = true;
}

C++/WinRT

If using the C++/WinRT projections, then you can implement this as:

void SetWindow(CoreWindow const & window)
{
    …
    auto navigation = SystemNavigationManager::GetForCurrentView();
    // UWP on Xbox One triggers a back request whenever the B
    // button is pressed which can result in the app being
    // suspended if unhandled
    navigation.BackRequested([](const winrt::Windows::Foundation::IInspectable&,
        const BackRequestedEventArgs& args)
    {
        args.Handled(true);
    });
}

4K

For UWP on Xbox One apps, the system always indicates a window size of 1920 x 1080 (i.e. 1080p). If the TV is running as 4K on an Xbox One S or Xbox One X, the swapchain content is automatically scaled up by the display hardware.

It is also possible to create a native 4k swapchain, but it’s recommended you only do this while running on an Xbox One X. You can check which device the UWP is running on via a new Windows 10 Fall Creators Update SDK (16299) API:

#include "Gamingdeviceinformation.h"
…
GAMING_DEVICE_MODEL_INFORMATION info = {};
GetGamingDeviceModelInformation(&info);
if (info.vendorId == GAMING_DEVICE_VENDOR_ID_MICROSOFT)
{
    switch (info.deviceId)
    {
    case GAMING_DEVICE_DEVICE_ID_XBOX_ONE:
    case GAMING_DEVICE_DEVICE_ID_XBOX_ONE_S:
        // Keep swapchain at 1920 x 1080
        break;

    case GAMING_DEVICE_DEVICE_ID_XBOX_ONE_X:
    case GAMING_DEVICE_DEVICE_ID_XBOX_ONE_X_DEVKIT:
    default: // Forward compatibility
        m_outputWidth = 3840;
        m_outputHeight = 2160;
        break;
    }
}

Note that if your UWP app has a Target Platform Minimum Version before 10.0.0.16299, then you need to guard the use of GetGamingDeviceModelInformation as follows:

#include <libloaderapi2.h>
extern "C" IMAGE_DOS_HEADER __ImageBase;
…
// Requires the linker settings to include
// /DELAYLOAD:api-ms-win-gaming-deviceinformation-l1-1-0.dll

if (QueryOptionalDelayLoadedAPI(
    reinterpret_cast(&__ImageBase),
    "api-ms-win-gaming-deviceinformation-l1-1-0.dll",
    "GetGamingDeviceModelInformation",
    0))
{
    GAMING_DEVICE_MODEL_INFORMATION info = {};
    GetGamingDeviceModelInformation(&info);
    if (info.vendorId == GAMING_DEVICE_VENDOR_ID_MICROSOFT)
    {
        switch (info.deviceId)
        {
        case GAMING_DEVICE_DEVICE_ID_XBOX_ONE:
        case GAMING_DEVICE_DEVICE_ID_XBOX_ONE_S:
            // Keep swapchain at 1920 x 1080
            break;

        case GAMING_DEVICE_DEVICE_ID_XBOX_ONE_X:
        case GAMING_DEVICE_DEVICE_ID_XBOX_ONE_X_DEVKIT:
        default: // Forward compatibility
            m_outputWidth = 3840;
            m_outputHeight = 2160;
            break;
        }
    }
}

You set the delay load via the Visual C++ project settings:

If you use a native 4k swapchain on Xbox One X and the TV is in a 1080p mode, then image is downscaled automatically by the display hardware which does have the effect of ‘super-sampling’ for better image quality. In other words, if you decide to render at native 4k, you should do so regardless of the TV setting.

HDR

UWP on Xbox One apps have limited access to the High-Dynamic Range (HDR) capabilities of the Xbox One S and the Xbox One X. For games looking to implement HDR, contact the ID@Xbox program.

Tools

The Visual Studio Graphics Diagnostics (a.k.a. VSPIX) supports UWP on Xbox One.

Note that neither the Xbox PIX nor the “new” PIX tool currently support UWP on Xbox One.

Related: Windows 10 Fall Creators Update SDK

DirectXMesh Update

$
0
0

The February 2018 release of DirectXMesh is available on GitHub. I wanted to call attention to this release in particular because I discovered an important and long-standing bug in the library that is now fixed.

First, the good news: I have implemented a vertex welding algorithm similar to the legacy function D3DXWeldVertices, and I've added support for Tom Forsyth's Linear-speed Vertex Cache Optimisation algorithm as an alternative to the Hugh Hoppe Transparent Vertex Cache Optimization algorithm that was originally ported from the deprecated D3DX9 library. The meshconvert tool was updated with a new -oplru switch to use the Forsyth algorithm, and the DirectX SDK Samples Content Exporter now supports an -optimization switch to control the algorithm selection as well (see the wiki for details).

To support vertex welding (which results in a number of 'unused' vertices), I also added a new helper function CompactVB. In the course of that work I realized that FinalizeVB, FinalizeVB, and FinalizeVBAndPointReps were all applying the vertex remap backwards. The original D3DX9 codebase used both kinds of vertex maps: oldLoc = vertexRemap[newLoc] and newLoc = vertexRemap[oldLoc]. The D3DX9 library and DirectXMesh are intended to expose only the first version maps to the client code (which is the most useful for copying around related attributes), but internally there are a number of places you need to use the inverse. It turns out I was returning the correct vertex remaps from OptimizeVertices, but then applied them incorrectly with my remap functions--but they were consistent so it still rendered correctly. Unfortunately this means it was always making the vertex buffer less efficient. Ooops. My bad. I've improved my test suite and the documentation here as well as fixing the remap functions.

Wavefront OBJ: In the December 2017 release I fixed the WaveFrontReader.h helper to support 'relative' indices which were missing from the original sample implementation I used to create the header, and in February 2018 I made a few more robustness improvements. The February 2018 versions of meshconvert and the uvatlas tool now use this improved version.

NuGet: The DirectXMesh library is now available on NuGet as well. I provide a Win32 desktop package suitable for use with VS 2015 Update 3 or VS 2017, as well as a UWP version.

Related: DirectXMeshDirectXTex and DirectXMesh now support Direct3D 12


VS 2017 (15.6 update)

$
0
0

The Visual Studio 2017 (15.6 update) is now available for download, and you should see the 'new update available' notification in the coming weeks--you can also get the update now by downloading the 'free trial' version of the installer which will let you update your system.

The latest VS 2017 Redistribution packages are available (x86, x64), as well as the Remote Debugging Tools (x86, x64). For more on the Visual Studio 2017 (15.6) update, see the release notes.

Compiler and CRT

VS 2017 (15.6) includes a new version of the C/C++ complier (19.13.26128). See this blog post for details on the latest C++17 Standard conformance as well as MSDN. Notably this includes some compile-time improvements, as well as better linker performance when doing /DEBUG:fastlink and map-file generation.

Note: Per this blog post, the _MSC_VER value is now 1913 instead of 1910, 1911, or 1912.

The C/C++ Runtime (14.13.26020) is included in this update. Remember that VS 2015 and VS 2017 share the same runtime redistributable binaries and that VS 2015 Update 3 is binary compatible with VS 2017--code or static library built with one can be linked to the other--, so this is the latest version for both.

Related: VS 2017 (15.5 update), Windows 10 Fall Creators Update SDK (15.4), VS 2017 (15.3 update)Windows 10 Creators Update SDK (15.1/15.2), Visual Studio 2017 (15.0)

GitHub, NuGet, and VSTS

$
0
0

There are April 2018 releases on GitHub for DirectX Tool Kit (DX11 / DX12), DirectXTex, DirectXMesh, and UVAtlas. These were more minor releases focused on code quality, fixing a few bugs, and cleaning up some new /analyze issues based on the C++ Core Checker rules that will be appearing in Visual Studio 2017 (15.7 update) which is currently in preview.

I’m mentioning these because there are some changes happening with NuGet where I’ve also been publishing new releases of many of these libraries that has some important implications I wanted to announce.

The Good

NuGet packages are getting support for digital signing, which means better security when consuming signed packages in your applications. Packages published by Microsoft now also have more official organizational ownership rather than being published by individual Microsoft developers private Microsoft Accounts.

See this NuGet blog post for more details.

To support digital signing, I’m setting up Visual Studio Team Services (VSTS) build support for my libraries so they can be more officially built than just sitting on my machine. Much of Microsoft’s internal processes have migrated to using VSO for building including my group’s samples work, so this is generally all goodness and it’s been a good learning experience making use of the cloud-based build services.

The Bad

One consequence of moving to the VSO build solution, however, is that I need to drop support for Visual Studio 2013, Windows Store 8.1, and Windows Phone 8.1. The VSO hosted build services support VS 2015 and VS 2017, so I will continue to support VS 2015 Update 3 & VS 2017 for Win32 desktop applications for Windows 7 SP1 or later, Universal Windows Platform (UWP) apps, and Xbox One XDK development.

As such, the April releases above will be the last to support Visual Studio 2013, Windows Store 8.1, or Windows Phone 8.1. The existing NuGet packages for these platforms are still available (directxtk_desktop_2013, directxtk_windowsstore_8_1, directxtk_windowsphone_8_1, and fx11_desktop_2013), but will no longer receive any updates--much like I had already done for the Windows Phone 8.0 package (directxtk_windowsphone_8) when I dropped VS 2012 support some time ago.

Mine are not the only open source packages from Microsoft so affected, so expect most of them to be dropping these platforms as well.

As an aside, this change is good news for me. This greatly reduces the number of configurations I maintain and let’s me focus on the more complete C++14 language and Standard library conformance in VS 2015 or later with a lot of messy conditional compilation. I realize it’s a potential hardship on some users of these libraries, but you can continue to use the April 2018 or earlier releases.

Note that Xbox One XDK development never supported VS 2013.

The Ugly

Another consequence of the move to the VSO build solution is that I can’t make use of the legacy DirectX SDK in those solutions that are published as NuGet packages. For the most part I don’t need the legacy DirectX SDK for anything since that’s one of the main motivations for doing these libraries in the first place. There is, however, one specific scenario that still require the legacy DirectX SDK: XAudio 2.7 support for Windows 7.

Up through the April 2018 release, the NuGet directxtk_desktop_2015 package includes DirectXTKAudioDX.lib which uses XAudio 2.7 to support Windows 7, but I will now have to make it include the DirectXTKAudioWin8.lib instead for the May 2018 and later versions of the NuGet package. That means if you using a project that is set up to use DirectX Tool Kit for Audio with Windows 7 (_WIN32_WINNT set to 0x0600 or 0x0601), you’ll now get a build failure including "Audio.h" or trying to link. The newer Win32 desktop NuGet packages will work fine if you are building for Windows 8 or later (_WIN32_WINNT set to 0x0602, 0x0603, or 0x0A00).

Use of the DirectXTKAudioDX.lib already required some gymnastics with the legacy DirectX SDK and imposed specific deployment requirements using legacy DirectSetup. If you need DirectX Tool Kit for Audio support on Windows 7, I recommend you move to using project-to-project references instead of the NuGet package.

The Win32 desktop NuGet package will still be built for Windows 7 SP1 support for the graphics, input, and math functionality so this only affects you if you are using DirectX Tool Kit for Audio. There are also no issues when using the UWP packages since XAudio 2.8 or later is always available on those platforms.

Windows 10 April 2018 Update SDK

$
0
0

The Windows 10 April 2018 Update (a.k.a. Version 1803) is now available along with the Windows 10 SDK (10.0.17134). The new SDK can be installed via VS 2017 (15.7 update) [currently in Preview] or as a standalone installer. This release includes some updates to DirectX 12, DirectWrite, and DXGI. See What’s New in Windows 10 for developers, build 17134.

VS 2015 Users: The Windows 10 SDK (15063, 16299, 17134) is officially only supported for VS 2017.

C++/WinRT: The new C++/WinRT headers for this Windows SDK are included. You no longer need to make use of the GitHub project (which is now archived) or the NuGet package when using C++/WinRT projections for the latest Windows 10 SDK. See this blog post.

Sample: The DirectX-Graphics-Samples repository of DirectX 12 samples has been updated to use the Windows 10 SDK (17134). This includes samples for the recently announced DirectX Raytracing API as well.

Related: Windows 10 SDK RTM, Windows 10 SDK (November 2015), Windows 10 Anniversary Update SDK, Windows 10 Creators Update SDK, Windows 10 Fall Creators Update SDK

VS 2017 (15.7 update)

$
0
0

The Visual Studio 2017 (15.7 update) is now available for download, and you should see the 'new update available' notification in the coming weeks--you can also get the update now by downloading the 'free trial' version of the installer which will let you update your system.

The latest VS 2017 Redistribution packages are available (x86, x64), as well as the Remote Debugging Tools (x86, x64). For more on the Visual Studio 2017 (15.7) update, see the release notes.

Compiler and CRT

VS 2017 (15.7) includes a new version of the C/C++ complier (19.14.26428). See this post and MSDN for details on the changes to C++ conformance.

Note: Per this blog post, the _MSC_VER value is now 1914 instead of 1910, 1911, 1912, or 1913.

The C/C++ Runtime (14.14.26405) is included in this update. Remember that VS 2015 and VS 2017 share the same runtime redistributable binaries and that VS 2015 Update 3 is binary compatible with VS 2017--code or static library built with one can be linked to the other--, so this is the latest version for both.

Windows 10 SDK: When installing a fresh copy of VS 2017 (15.7) the default Windows 10 SDK is now the April 2018 Update (17134). Also note that the Windows 10 SDK (17134) is once again one VS install component (Microsoft.VisualStudio.Component.Windows10SDK.17134) instead of multiple components (Microsoft.VisualStudio.Component.Windows10SDK.*.Desktop, Microsoft.VisualStudio.Component.Windows10SDK.*.UWP, Microsoft.VisualStudio.Component.Windows10SDK.*.UWP.Native) as it was for 15063 / 16299.

C++/WinRT: With the Windows 10 SDK (17134), you no longer need to use the GitHub project or NuGet package to obtain the C++/WinRT projection headers as they are now a part of the Windows 10 SDK.

Static Analysis: The 15.7 update version of /analyze now includes part of the C++ Core Guidelines checkers in the default native ruleset. For more details, see this blog post. The current state of the new /analyze is quite a bit noiser than it was before, so I expect some further refinement in future releases. If you have <CodeAnalysisRuleSet>AllRules.ruleset</CodeAnalysisRuleSet> in your project files, you'll want to change it since that now pulls in all the C++ Core Guidelines Checker rules which is highly likely to be an overwhelming mass of new warnings.

__cpluplus: The preprocessor symbol __cplusplus is often used in guards like #ifdef __cplusplus to handle both C and C++ scenarios, but it also has a value that is supposed to indicate which C++ Standard the compiler conforms to. For various reasons, the Visual C++ compiler has been returning "199711" for ages. The 15.7 update includes a new compatibility switch /Zc:__cplusplus which will cause the Visual C++ compiler to report the proper value of "201402" (or "201703" if using /std:c++17). It is off by default because it has the potential to break a lot of code. Developers are strongly encouraged to turn on this switch and clean up their codebases for a future where this is on by default. See this blog post for more information.

Spectre mitigations: This update includes some changes to the Spectre mitigation compiler support. See this blog post for details.

GitHub: I've updated directx-vs-templates, DirectX Tool Kit (DX11 / DX12), DirectXTex, DirectXMesh, UVAtlas, DXUT, and FX11 for VS 2017 (15.7) support. Direct3D 12 developers should also pick up the latest version of D3DX12.H from DirectX-Graphics-Samples

Related: VS 2017 (15.6 update), VS 2017 (15.5 update), Windows 10 Fall Creators Update SDK (15.4), VS 2017 (15.3 update)Windows 10 Creators Update SDK (15.1/15.2), Visual Studio 2017 (15.0)

VS 2017 (15.8 update)

$
0
0

The Visual Studio 2017 (15.8 update) is now available for download, and you should see the 'new update available' notification in the coming weeks--you can also get the update now by downloading the 'free trial' version of the installer which will let you update your system.

The latest VS 2017 Redistribution packages are available (x86, x64), as well as the Remote Debugging Tools (x86, x64). For more on the Visual Studio 2017 (15.8) update, see the release notes. See this post for details on the changes to the Standard Library.

Compiler and CRT

VS 2017 (15.8) includes a new version of the C/C++ complier (19.15.26726). This includes some improvements to the SSA Optimizer, as well as some additional performance improvements for the linker. This also fixes some codegen bugs including this one.

Servicing:

  • 15.8.4 updates the compiler to 19.15.26729

A new C++ debugging feature in VS 2017 (15.8) known as "Just My Code" stepping (JMC). For more details, see this blog post.

There's a newly rewritten C++11/C99-compatible preprocessor in progress you can try out with /experimental:preprocessor. For more details see this blog post.

Note: Per this blog post, the _MSC_VER value is now 1915 instead of 1910, 1911, 1912, 1913, or 1914.

The C/C++ Runtime (14.15.26706) is included in this update. Remember that VS 2015 and VS 2017 share the same runtime redistributable binaries and that VS 2015 Update 3 is binary compatible with VS 2017--code or static library built with one can be linked to the other--, so this is the latest version for both.

C++/WinRT: The current C++/WinRT headers in the Windows 10 SDK (17134) are not fully compatible with the latest implementation of /permissive- in VS 2017 (15.8). This will be fixed in the next Windows 10 SDK. For now you can work around the issue leaving Conformance Mode enabled by adding /Zc:twoPhase- to the Additional Options project setting. You can also can try a Windows Insider SDK Preview.

Xbox One: By default /JMC is enabled with VS 2017 (15.8) in Debug configurations which can lead to a link error when using the Xbox One XDK (unresolved symbol __CheckForDebuggerJustMyCode). You can easily resolve this by going to your project settings under C/C++ -> General and setting "Support Just My Code Debugging" to "No", and then rebuild. This will be fixed in a future Xbox One XDK QFE at which time you can re-enable this feature if desired.

JMC: If you are shipping static libraries built from C++ code using VS 2017 (15.8), you probably want to turn off JMC anyhow to avoid forcing your customers to use 15.8, which otherwise would be compatible with 15.5, 15.6, and/or 15.7 as well. BTW, if you want the same static library to also work with VS 2015, then you are probably better off producing it with VS 2015 Update 3.

Static analysis: As I mentioned with the VS 2017 (15.7 update), the /analyze switch now includes some C++ Core Guidelines checker rules per this blog post. With VS 2017 (15.8 update), a fair amount of the 'noise' introduced with this change has been addressed.

GitHub: I've updated DirectX Tool Kit (DX11 / DX12), DirectXTex, DirectXMesh, and UVAtlas with changes for VS 2017 (15.8), mostly for /analyze cleanup. There's also a new release of directx-vs-templates with a few minor tweaks.

Related: VS 2017 (15.7 update), VS 2017 (15.6 update), VS 2017 (15.5 update), Windows 10 Fall Creators Update SDK (15.4), VS 2017 (15.3 update)Windows 10 Creators Update SDK (15.1/15.2), Visual Studio 2017 (15.0)

Viewing all 44 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>