DirectXMath | DirectXMath is an all inline SIMD C++ linear algebra | Game Engine library

You're doing invalid memory accesses when reading the vertex and pixel buffers.

Also, on my computer, both shaders have a dozen of kbytes whilst the memory buffer you're reading them to has only 4096 bytes.

To fix your problem, increase the size of the memory buffer you're using to read the shader bytecode from disk and don't forget to update the elementcount in fread_s().

e.g.,

Renderer.cpp @ 35

You should use XMVectorSet instead of XMVECTORSet(This function does not exist)

Function definition on msdn

Those functions are 'helpers' included in various starter templates and samples, but are not part of the actual Windows APIs in the Windows SDK. In particular, you will see them in the samples from the official DirectX 12 Samples GitHub for Win32 desktop.

• ThrowIfFailed is a simple "if COM returned a failure, throw a C++ exception" helper. This is because you should always check the return value of any COM function that returns HRESULT instead of void, but in 'working' programs most of the time any failure code from Direct3D in many places is a 'fast-fatal' error. The 'official' desktop samples for DX12 define it in DXSampleHelper.h, but many other templates put it into the pch.h precompiled header to make sure it's defined globally. See this wiki page for more details.

• GetHardwareAdapter is another helper. When you create a DirectX 11 device on any modern versions of Windows, you can pretty safely assume there's some Direct3D adapter there depending on your minimum Direct3D Hardware Feature level. With DirectX 12, you really need to check as it's quite possible that you have both a DX11 and a DX12 capable device on your system. See this blog post for more details on creating a DirectX 12 device.

• The Win32Application namespace is just a really simple WndProc and window helper. You can see the implementation here cpp / h

• GetAssetFullPath is another helper, but this one is more specific to the 'official' DirectX 12 samples. It basically deals with the fact that when doing development in Visual Studio, the 'current working directory' is typically the project folder, but the various shader blobs (cso files) built by Visual Studio are found next to the EXE in Debug, Release, etc. You can find it here.

This is a 'quirk' of Win32 desktop development since there's no standard packaging/setup/deployment system. For UWP and Xbox One development, the packaging typically places the EXE and CSO files next to each other along with other assets, and the Current Working Directory is set to the root of the 'package' at runtime.

Personally, I deal with the same issue slightly differently in my ReadData helper.

Another common issue is that the various D3DX12* helper functions are also not part of the Windows SDK. Instead you get D3DX12.H as part of a DirectX project template or from GitHub. The documentation is on Microsoft Docs.

I have a set of DirectX basic templates for Visual C++ hosted on GitHub you might want to look at. They include the DeviceResources module for handling your basic DirectX device when you are just getting started, the StepTimer helper, as well as D3DX12.h.

See this blog post and DirectX Tool Kit for DX12 for some general tips.

If you are really new to DirectX, you should seriously consider working with DirectX 11 before tackling DirectX 12.

TL;DR: This is a compiler bug likely due to bad code-generation.

The weird output happens only when using the x86 (32-bit) compiler, not when using the x64 (64-bit) native compiler. I tried a few different ways of outputting the results, and they are consistently weird for x86 but correct for x64.

• It seems to happen in both Debug and Release (optimized) configurations, and with both /fp:fast and /fp:precise.

• This does not happen with x64 native code or with x86 if you use /arch:IA32.

• I'm able to reproduce the same issue with VS 2017 (15.9.11) as well as VS 2019 (16.0.3).

When you see FXMVECTOR, CXMVECTOR, GXMVECTOR, or HXMVECTOR just read XMVECTOR. Same for FXMMATRIX and CXMMATRIX vs. XMMATRIX. It's just some typedef magic stuff I had to do to support the various calling conventions for x86 __fastcall, x64 __fastcall, x86/x64 __vectorcall, and Windows on ARM which are all subtlety different.

For documentation details on these types, see Microsoft Docs.

If you are new to DirectXMath, you probably want to take a look at the Simple Math wrapper in the DirectX Tool Kit.

The underlying SIMD instructions are typeless. You can treat the same data as 4 floats or as 4 integers (or 8 shorts or 16 bytes). DirectXMath usually works with 4 floats, which is what your XMVECTOR is getting from XMVectorSet.

If you used float x = XMVectorGetX(vector); you'd get "1.0" back.

Alternatively, you could have used XMVECTOR vector = XMVectorSetInt(1, 2, 3, 1);

See DirectXMath Programmer's Guide as well as the GitHub project.

There are a couple of issues here that are causing your code to fail.

First, you cannot use a member of an XMVECTORI32 to provide a template parameter to XMVectorPermute. This is not because of the type difference (same thing happens with XMVECTORU32). I believe the issue is because the array i is not declared as const, and the value must be constant to be used as a template parameter. In any case, VS2017 refuses to compile the code.

Second, you cannot specialize a template function without providing a body for that function. This would mean your second line is incomplete, and would need to have an implementation written by you in order to compile.

This doesn't mean you're SOL though, just that you need to change your approach. If the template parameters are always constant (and it looks like they should be, in your code), you can define a function that takes the two vector parameters and specifies the exact permute constants to use for that particular operation.

The following code is an example of this:

Lets look at the HR macro:

Frank Luna's book is overall a great introduction to the Direct 11 API, but unfortunately suffers from heavily utilizing the legacy DirectX SDK which is deprecated per MSDN. One of those aspects is that he's actually using the xnamath library (a.k.a. xboxmath version 2) instead of the DirectXMath library (a.k.a. xboxmath version 3)

See Book Recommendations and Introducing DirectXMath

I made a number of changes when reworking the library as DirectXMath. First, the types are actually in C++ namespaces instead of the global namespace. In your headers, you should use full name specification: