I wanna start learning DirectX in Visual C++ 2010, but it says that d3dx11 and d3dx9 can't be found when I include d3dx9.h, I can play games in DirectX 11 and dxdiag says my computer is running directX 11, but when I searched for DirectX 11 in C drive and my D-Drive, it couldn't find anything. So I decided to install DirectX 11 and then I got a folder after installing, but it didn't have any include or bin folders, so I couldn't go to properties and VC++ and add the include directories. Decided to try DirectX 9 instead to start with, but when I installed DirectX 9 June 2010 version, I went to C\Microsoft DirectX SDK (June 2010) there is no directories, only DirectX utilities and documentation for c++ and sample browser and Command prompt. So I don't really know what to do anymore, I have tried to install d3dx9.lib and put in in the default lib folder for VS 2010. but no success, But I have DirectX 9 2004 summer libraries and Include folders set up for visual c++, but that is such an old version so it doesn't include d3dx9.lib. I'm running Windows 8.1 64 bit OS.
The DirectX SDK and all version of the D3DX libraries are both deprecated.
The 'modern' solution is to use the Windows 8.x SDK which comes with Visual Studio 2012 and Visual Studio 2013. You can install the Windows 8.1 SDK 'standalone' and use it with Visual Studio 2010 by using .props files. See MSDN and this blog post for all the details.
You can mix using the Windows 8.x SDK with the legacy DirectX SDK in order to continue to use D3DX for Win32 desktop applications--you cannot use the DirectX SDK for Windows Store apps, Windows phone, or Xbox One. See the instructions on MSDN for how to handle the include/lib path directories. If you are going to continue to use the legacy DirectX SDK, you need to be aware of a number of things:
The DirectX SDK (June 2010) installer has some compatibility issues with systems that have VS 2010 SP1 REDIST installed. See this post.
The DirectX SDK (June 2010) does not have the latest developer debug runtime for Windows 8.1. You have to install the Windows 8.1 SDK, VS 2013, or the VS 2013 remote debugging tools to get the DEBUG layers and REFERENCE device. See this post.
There is no support for the Direct3D 9 DEBUG device on Windows 8.1.
The "PIX for Windows" tool in the DirectX SDK does not work for Direct3D 10.x or Direct3D 11.x on Windows 8.1, Windows 8.0, or Windows 7 SP1 with the DirectX 11.1 Runtime installed. Use the Visual Studio 2013 Graphics Diagnostics, or Intel/AMD/NVIDIA's GPU tools.
If you are deploying a game that needs the legacy DLLs like D3DX, be sure to use the April 2011 refreshed version of DXSETUP and not the copy that is in the DirectX SDK (June 2010). See this post and be sure to read Not So DirectSetup.
Given all that, your life will be a lot easier if you just use Direct3D 11 and avoid the legacy DirectX SDK and D3DX entirely. You can find many Direct3D 11 replacements for D3DX that only requires the Windows 8.x SDK along with a bunch of updated samples. See Living Without D3DX, DirectX Tool Kit, and DirectX SDK Samples Catalog. You can get all that to work with VS 2010, but it's a lot easier to get Visual Studio 2013 Express for Windows Desktop (for Win32 desktop applications) and/or Visual Studio 2013 Express for Windows (for Windows Store apps and Windows phone apps).
PS: Even back when the DirectX SDK was still the supported way to get Direct3D headers for VS 2010, it was not available until you manually added the include/path directories to your project. That's why you can't include "d3dx9.h" in your project freshly created.
Related
I am really rusty when it comes to writing code on Windows. From what I know for 2015 there was a change in the way even the standard library is shipped (UCRT in particular).
So now I am standing in front of a Visual Studio 2015 project targeting Windows 8.1 SDK with build toolset v140 that doesn't compile due to a library (part of the project) not being able to find sstream, memory, excpt. I even checked excpt and the error comes from Windows.h.
I also have Visual Studio 2017. I went on using the installer to install Windows SDK. The problem is there are many versions of it...
Currently I have (quoting 1:1 what Visual Studio 2017 installer is giving me):
VC++ 2015.3 v14.00 (v140) toolset
VC++ 2017 version 15.9 v14.16 latest v141 tools
Windows Universal CRT SDK
Visual C++ ATL for x86 and x64
Visual C++ MFL for x86 and x64
Windows 10 SDK (10.0.10240.0)
Windows 10 SDK (10.0.10586.0)
Windows 10 SDK (10.0.14393.0)
Windows 10 SDK (10.0.15063.0) for Desktop C++ [x86 and x64]
Windows 10 SDK (10.0.15063.0) for UWP: C#, VB, JS
Windows 10 SDK (10.0.15063.0) for UWP: C++
Windows 10 SDK (10.0.16299.0) for Desktop C++ [x86 and x64]
Windows 10 SDK (10.0.16299.0) for UWP: C#, VB, JS
Windows 10 SDK (10.0.16299.0) for UWP: C++
Windows 10 SDK (10.0.17134.0)
Windows 10 SDK (10.0.17763.0)
Windows 8.1 SDK
Windows Universal C Runtime
I'm assuming Windows 8.0 SDK is not listed, since it's an essential component that gets shipped with Windows 10 upon installing the OS.
When looking for memory.h it appears that it's only in the ucrt subdirectory of each Windows 10 SDK (e.g. C:\Program Files (x86)\Windows Kits\10\Include\10.0.14393.0\ucrt\memory.h.
I come from Linux where in all honesty things appear to be simpler when it comes to setting up a development environment (I can only imagine what it is to develop cross-platform on Windows -_-) so I am probably missing something rather obvious here.
Can I mix includes from different SDKs? (here: Windows 10 and 8.1 SDK) Upgrade is currently not an option. If that's not possible how do I deal with the situation?
You're coming from Linux, where things are mixed up. Windows is actually a lot cleaner.
The Windows OS headers come from the SDK.
The language headers come from the language implementation
C++ has headers such as <memory> (note the lack of .h). These will come from Visual Studio. This is not the same header as memory.h. Similarly, <sstream> is another C++ and therefore Visual Studio header.
The UCRT is a bit of a special case - it's a Universal C RunTime. C as a language is stable (which is a nice way to say there's not much improvement anymore). Windows ships a fairly decent chunk of the C standard library in the UCRT. Since C++ includes the C Standard Library in its own, Visual Studio can build on top of the UCRT.
Another major difference is that the Windows SDK's are SDK's for a particular Windows version and many preceding versions. There's no need to use the Windows 8.1 SDK; everything in there is also in all the Windows 10 SDK's. Also, the Windows SDK's are not tied to Windows itself. You can develop for Windows 10 using the Windows 10 SDK on Windows 8. There would never be a reason to mix two SDK's.
Before I start off I know this is quite a common question, I did search for answers before posting here. Unfortunately, I had no luck.
In my code I include the file like this:
#include <d3dx9.h>
Now the error shows up: Cannot open source file d3dx9.h
In my Include Directories I did enter the path to where it is (if I look it up manually through my files, I can see it there).
The path is: C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include
I also set the Library Directory: C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\x64
x64 since I am running a 64 bit system.
I'd highly appreciate it if someone could take the time to post a suggestion.
Greetings.
Visual Studio 2015 includes the Windows 8.1 SDK which is newer than the headers in the legacy DirectX SDK. The Windows 8.1 SDK includes all the DirectX headers and libraries, but does not contain the now deprecated D3DX (D3DX9, D3DX10, D3DX11) utility library which is why it is "missing".
D3DX9, D3DX10, and D3DX11 are only available in the legacy DirectX SDK. With VS 2010, the VC++ Directory settings you were supposed to use were as follows for Win32 (x86) settings:
<ExecutablePath>$(DXSDK_DIR)Utilities\bin\x86;$(ExecutablePath)</ExecutablePath>
<IncludePath>$(DXSDK_DIR)Include;$(IncludePath)</IncludePath>
<LibraryPath>$(DXSDK_DIR)Lib\x86;$(LibraryPath)</LibraryPath>
and this for x64 native:
<ExecutablePath>$(DXSDK_DIR)Utilities\bin\x64;$(DXSDK_DIR)Utilities\bin\x86;$(ExecutablePath)</ExecutablePath>
<IncludePath>$(DXSDK_DIR)Include;$(IncludePath)</IncludePath>
<LibraryPath>$(DXSDK_DIR)Lib\x64;$(LibraryPath)</LibraryPath>
With VS 2012 or later, you have to reverse them since most of the headers in the Windows 8 SDK replace the older DirectX SDK:
<ExecutablePath>$(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x86</ExecutablePath>
<IncludePath>$(IncludePath);$(DXSDK_DIR)Include</IncludePath>
<LibraryPath>$(LibraryPath);$(DXSDK_DIR)Lib\x86</LibraryPath>
and
<ExecutablePath>$(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x64;$(DXSDK_DIR)Utilities\bin\x86</ExecutablePath>
<IncludePath>$(IncludePath);$(DXSDK_DIR)Include</IncludePath>
<LibraryPath>$(LibraryPath);$(DXSDK_DIR)Lib\x64;</LibraryPath>
See MSDN, Where is the DirectX SDK (2015 Edition)?, The Zombie DirectX SDK, and Not So Direct Setup.
With all that said, you probably shouldn't be using legacy Direct3D 9 anyhow. Using DirectX 11 with one of the modern replacements for D3DX is a better, cleaner option and doesn't require the legacy DirectX SDK. See Living without D3DX.
If you are specifically targeting to run a program on Windows XP SP3 with Direct3D 9, you'll be using the v140_xp Platform Toolset which uses the Windows 7.1A SDK, not the Windows 8.1 SDK. Therefore, you go with the old-school include order. See this post for details.
I compiled my code in VS C++ 2010. If I use debug version, everything is okay!
If I want to make release version, I've got communicat:
main.cpp(7): fatal error C1083: Cannot open include file: 'd3dx11.h': No such file or directory
I use DirectX 11. What should I do?
As noted on MSDN, all versions of D3DX are deprecated including D3DX9, D3DX10, and D3DX11. You can certainly continue to use the deprecated libraries by using the legacy DirectX SDK. Remember that with VS 2010, you have to manually add the include/lib paths to your VC++ Directories properties page of your project to use the DirectX SDK with it.
For 32-bit Win32 configurations:
$(DXSDK_DIR)Utilities\bin\x86;$(ExecutablePath)
$(DXSDK_DIR)Include;$(IncludePath)
$(DXSDK_DIR)Lib\x86;$(LibraryPath)
For x64 native configurations:
$(DXSDK_DIR)Utilities\bin\x64;$(DXSDK_DIR)Utilities\bin\x86;$(ExecutablePath)
$(DXSDK_DIR)Include;$(IncludePath)
$(DXSDK_DIR)Lib\x64;$(LibraryPath)
If you were able to get #include <d3dx11.h> to work for DEBUG builds, but not RELEASE, you probably failed to set the VC++ Directories for All Configurations / All Platforms.
Another option would instead be to move to VS 2012 or VS 2013 which includes the Windows 8.x SDK which has the DirectX SDK integrated into it. There you'd make use of DirectX Tool Kit, DirectXTex, DirectXMesh, and/or other replacements for legacy D3DX.
Note if you were making use of the legacy DirectX SDK to continue to use D3DX11 and were also using the Windows 8.x SDK (such as with VS 2012 or VS 2013), then you'd have to reverse the include order above because the legacy DirectX SDK headers are older than the ones in the Windows 8.x SDK.
$(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x86
$(IncludePath);$(DXSDK_DIR)Include
$(LibraryPath);$(DXSDK_DIR)Lib\x86
For x64 native configurations:
$(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x64;$(DXSDK_DIR)Utilities\bin\x86
$(IncludePath);$(DXSDK_DIR)Include
$(LibraryPath);$(DXSDK_DIR)Lib\x64
Note you can get the Windows 8.1 SDK and DirectX Tool Kit to work with VS 2010 as noted here, but if you can I'd highly recommend using the VS 2013 Community edition if you don't have the budget for VS 2013 Professional or better.
My OS is 64Bit Windows 7.
I wanted to build the DirectX Sample in
C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Samples\C++\Direct3D10\Tutorials\Tutorial02.
but when I build error occured with fatal error
LNK1104: 'winmm.lib' can't open the file.
I reinstalled Direct SDK, but no change. I also added the path (include, lib) to the settings.
If I remove 'winmm.lib' from the project settings, 'comctl32.lib' can't be opened.
both libs were already present in properties>Linker>Input.
How can I solve this problem?
Just put the line below in stdafx.h
#pragma comment(lib, "winmm.lib")
winmm.lib isn't part of the DirectX SDK but is part of the Windows SDK.
Latest Windows SDK versions were also heavily reorganized but it includes the library you're looking for.
If you are trying to build any of the legacy DirectX SDK samples with VS 2012 or VS 2013, you need to modify the include/libs paths per the instructions on bottom of the page on MSDN. The most important change is that you must reverse the Include/Lib path order:
For VS 2010 it was:
$(DXSDK_DIR)Include;$(IncludePath)
$(DXSDK_DIR)Lib\x86;$(LibraryPath) or $(DXSDK_DIR)Lib\x64;$(LibraryPath)
For VS 2012/2013 it has to be:
$(IncludePath);$(DXSDK_DIR)Include
$(LibraryPath);$(DXSDK_DIR)Lib\x86 or $(LibraryPath);$(DXSDK_DIR)Lib\x64
Of course a better option is not spend time learning the older Direct3D 10 API at all, and use the latest Direct3D 11 Win32 desktop tutorials on MSDN Code Gallery. In fact, I've posted many of the legacy DirectX SDK samples there so they work fine with VS 2012/2013 Express for Windows Desktop and VS 2012/2013 Pro+ as-is without the DirectX SDK at all.
Read these blog posts:
DirectX SDK Samples Catalog
DirectX SDK Tools Catalog
Living without D3DX
DirectX SDKs of a certain age
And review these CodePlex projects:
DirectX Tool Kit
DirectXMesh
DirectXTex
DXUT for Direct3D 11
Effects 11
I am very confused on what I need in order to use the latest version of the DirectX SDK.
There is the DirectX SDK (June 2010), which is apparently deprecated and there is the Windows SDK for Windows 8.1.
What is so confusing is that I can't figure out if the Windows SDK for 8.1 will work using Windows 7 and Visual Studio 2013 for Desktop, or if I have to use the DirectX SDK (June 2010) with Windows 7 and Visual Studio 2013 for Desktop.
Also, if I use Windows SDK for 8.1, how do I include it in my Visual Studio Projects. Any help?
The DirectX SDK has been rolled into the Windows SDK starting with version 7.0. Unless you need certain deprecated features such as DXUT, specifically the runtime shader compiler, you'll be fine just running with the Windows SDK.
If, however, you want to use the deprecated features of the DirectX SDK, you'll need to include both SDKs, with the Windows SDK set to have higher priority than the DX SDK. If you include both and see a redefinition warning, then you included them in the wrong order.
If you have Visual Studio 2013 Express for Windows Desktop (or VS 2013 Pro or better), then you have the Windows 8.1 SDK and will use it for any C++ project by default. To support 'down-level' systems such as Windows 8.0, Windows 7 and/or Windows Vista, you need to set the _WIN32_WINNT preprocessor symbol appropriately (_WIN32_WINNT=0x0601 for Windows 7 or later). There's nothing else special you need to do, and you can use DirectX 11.0, DirectXMath, XInput 9.1.0, etc. on all these platforms without any need to use the legacy DirectX SDK. The HLSL compiler (D3DCompile #47) DLL is available in the Windows 8.x SDK to just copy into your apps folder for Win32 desktop apps, although on Windows 8.1 it is already part of the OS as well.
Where is the DirectX SDK (2013 Edition)?
Where is the DirectX SDK?
Ideally you would avoid using D3DX11 and use any of the many alternatives available that support Win32 desktop apps on Windows Vista or later.
You can of course still also use the legacy DirectX SDK with the Windows 8.x SDK (which unfortunately you have to for XAudio 2.7 on Windows Vista/Windows 7; XAudio 2.8 is part of Windows 8.x), but you need to remember that the include/lib path order is reversed since the headers in the DirectX SDK are now older than those in the Windows 8.x SDK. This is covered on MSDN. Remember that if you use the legacy DirectX SDK components like D3DX, XAudio 2.7, XInput 1.3, XACT, D3DCompiler #43, etc. then you also need to rely on the legacy DirectSetup deployment. In this case, it is recommended you make use of the refreshed version of the REDIST rather than the one that shipped in the legacy DirectX SDK.
BTW, if you are trying to target Windows XP with the "v120_xp" Platform Toolset, you are actually using the Windows 7.1 SDK and not the Windows 8.x SDK since the Windows 8.x SDK does not support Windows XP. See this post for the many caveats of this scenario, or save your sanity and just let Windows XP go away :)