Will about a DXUT for Direct3D12?

Coordinator
Jun 5, 2016 at 9:08 PM
Edited Jun 5, 2016 at 9:08 PM
Q: DXUT only supports Direct3D 11. Will you have a Direct3D 12 version?
Coordinator
Jun 5, 2016 at 9:08 PM
Edited Jun 5, 2016 at 9:37 PM
DXUT for Direct3D 11's primary purpose is to support porting legacy Direct3D 11 samples off the end-of-life old DirectX SDK--the same reason there's an Effects 11--, and really isn't intended for new projects. It still works fine for deved to some extent, but it has accumulated a decade+ of complexity that is largely irrelevant. The latest version no longer supports Direct3D 9, and a huge amount of the complexity came from supporting multiple versions of Direct3D at the same time. While there are certainly useful scenarios for a game to support both Direct3D 11 and Direct3D 12 at the same time, it makes more sense for such a game to just use one or the other exclusively.

The main value of Direct3D 12 is much more control over CPU-side costs than Direct3D 11, but if you write an abstraction that makes DX12 look like DX11 you lose most of that anyhow. If you are writing a Direct3D12 only application, then you already require Windows 10 and you should consider the UWP platform instead of a classic Win32 desktop app.

DXUT also heavily relied on the deprecated D3DX utility library for things like loading textures. D3DX9, D3DX10, and D3DX11 are all end-of-life with the DirectX SDK. D3DX12 is just a header with some helper code and doesn't have any of the support functionality of the old D3DX library. These utility scenarios are addressed by DirectX Tool Kit, DirectXTex, DirectXMesh, DirectXMath, and UVAtlas. I have a version of DirectX Tool Kit for DirectX 12 right now which I'll be wrapping up and releasing in the next month, along with DX12 updates for DirectXTex.

The DXUT framework provides an 'appmodel' for development, which is better served for deved by the Direct3D Game VS templates (DX11 and DX12 for both Win32 classic desktop and UWP) and the DeviceResources abstraction. Much of DXUT is tied up in exclusive fullscreen handling, mode enumeration, and really complex tweakable UI. This is surely overkill for a game, and is much more complexity than you really need in a sample (it was most useful for tests and demos). Exclusive fullscreen mode has a few specific uses, but most games actually use 'fake fullscreen'. The Direct3D Game template aligns better with the Universal Windows Platform as well as the Xbox One XDK model for samples, and both those platforms use backbuffer scaling not display mode changes to scale pixel-fill costs which you can also use in classic Win32 desktop apps.

Finally there's the GUI widgets in DXUT that render for Direct3D. The Input Method Editor (IME) edit there is rather buggy and the APIs it uses are all deprecated. The basic widgets could be useful in another form, but that's about it.

As such, it's not clear what purpose a DXUT for Direct3D 12 would really serve. The "glut" style of framework is certainly appealing to some, but many find the C callback model jarring alongside the C++ model of the COM APIs and other libraries. The macro-heavy HRESULT-based error handling in DXUT is also very 'old-school', where modern samples are using C++ Exception Handling and the ThrowIfFailed helper which is much easier to scan and use.

While some game engine prototypes have used DXUT as a starting point in the past, using it as the basis of a full engine is often quite problematic as the DXUT codebase suffers from major bit rot.
Marked as answer by walbourn on 6/5/2016 at 1:08 PM