On loading up a direct x 11 SDK project example, after linking all Libs./includes ETC that I was given an error from; I came across the following within an fx file.
VS version : VS ultimate 2013
Example name : 'DepthOfFeild10.1'
SDK : 'Microsoft DirectX SDK (February 2010)'
fx file name : 'DepthOfField10.1.fx'
error : Error 1 error X3000: syntax error: unexpected token 'cb0'
Perhaps I'm missing a lib/tool/set-up procedure ?
(Running Debug, X64)
Advice appreciated.
First of all, if you are trying to use VS 2013 and the legacy DirectX SDK together, be sure to read MSDN.
You need to use a different include/lib/executable path order with VS 2012 and later than the default VS 2010 projects that come with the legacy DirectX SDK February 2010 and June 2010 releases.
Many of the legacy DirectX SDK samples have been updated to remove the need to use the legacy DirectX SDK at all since VS 2013 and the Windows 8.1 SDK are generally sufficient. These are published to GitHub. See DirectX SDK Samples Catalog. DepthOfField10.1, however, is not one of these because it's an AMD sample. You can find AMD's version of it in their archive.
Start with the DirectX SDK (June 2010) version of DepthOfField10.1 (install it from the sample browser).
Open the DepthOfField10.1_2010.sln file and let it Upgrade the VC++ Tools and Libraries to v120.
Edit the Project Properties -> VC++ Directories:
For all configurations and the Win32 Platform, set it to:
Executable Directories: $(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x86
Include Directories: $(IncludePath);$(DXSDK_DIR)Include
Library Directories: $(LibraryPath);$(DXSDK_DIR)Lib\x86
For all configurations and the x64 Platform, set it to:
Executable Directories: $(ExecutablePath);$(DXSDK_DIR)Utilities\bin\x64;$(DXSDK_DIR)Utilities\bin\x86;
Include Directories: $(IncludePath);$(DXSDK_DIR)Include
Library Directories: $(LibraryPath);$(DXSDK_DIR)Lib\x64
If you were using VS 2015, then you also need to add the blog version of DXERR and remove the legacy DirectX SDK version of dxerr.lib from the project. A quick hack of DXUT is needed to resolve the ASCII/UNICODE differences. This is needed because VS 2015 includes some C99 related standard library changes that fail to link with the old version of strsafe.h used to build the legacy DirectX SDK.
Once this is done, it builds and runs as is.
Note: Most of the Direct3D 10 samples in the legacy DirectX SDK make use of the old Effects (FX) system. There's a Direct3D 11 version of Effects available, but the HLSL compiler support for Effects is officially deprecated. See Effects for Direct3D 11.
If the problem is happening in our own projects, then likely you have mis-configured the FXC command-line for building that .fx file.
Related
Some libraries are available to download as pre-compiled binaries, usually in specific architecture (x32 or x64) but I have also noticed that some pre-compiled binaries are splitted based on visual studio version, for example: vc17_x64. Let's assume that I use visual studio 2019. Does it mean that I have to use binaries precompiled for vc2019 or build a library from source when apropriate version is not available ? It's not clear for me because some pre-compilied binaries don't contain information about visual studio version.
If a pre-compiled library has Visual Studio version info you should use that version of Visual Studio to work with the library. This is not always the case though, as often enough happens that an older (with respect to VS version) library contains code that is a subset of the newer VS's header and runtime SDK files (.NET, C/C++, Windows SDK, etc). The other way around, when the library is newer can also work but it's far less frequent. You can try, if it doesn't work for your particular library and VS version then you should consider matching versions, rebuilding not always works for the same reasons of code changes.
If a library doesn't contain VS version info then it's reasonable to assume that it's portable/compatible up to operating system (Windows, Linux, etc) and programming language version (C++ 11, C++ 14, C# 7, C# 8, etc). However, VS version comes into play here as well, not every VS runs in every Windows, neither it supports the same runtimes, SDKs, and language(s) version. You should always check the library documentation for recommended working environment, if this info doesn't exist then it's trial and error and/or community consulting.
So, I've got Windows 10.0.18358.1 installed, latest Visual Studio (17, not bothering with 19 as of yet), updated (Insider) Windows SDK which should include the DX12 SDK.
And, yet, I have no DXSDK_DIR environment variable set.
I can see all of the DX and D3D headers and libs in the windows kits folder, but their distribution doesn't really correspond to a typical include/bin/lib structure.
Suggestions on how to correct this? I'd settle for copy of anyone's set output
that has this working.
(DirectML tag is because that is the feature that I require, and the source of all of this insanity.)
The DXSDK_DIR variable was only used by the legacy DirectX SDK and the 'beta DirectX 12 SDK' test vehicle, it's not used by the Windows 10 SDK as the standard WindowsSDKDir already includes the required headers & libraries.
If you are building with the Visual Studio build system, you don't have any special setup to use the DirectX 12 headers as they are all in the path already. Likely, your project is set to use the 10.0.17763 Windows 10 SDK by default, so to use the Windows 10 Insider SDK, you'll need to modify the project settings <WindowsTargetPlatformVersion> element to reference the newer 10.0.18xxx version.
If you are using some more manual build system, then you should use the include paths for the Windows 10 SDK side-by-side structure:
%WindowsSdkDir% is typically "C:\Program Files (x86)\Windows Kits\10\"
%WindowsSDKVersion% is something like "10.0.17763.0\"
%arch% is "arm", "arm64", "x64", or "x86'
INCLUDE=%WindowsSdkDir%include\%WindowsSDKVersion%shared;
%WindowsSdkDir%include\%WindowsSDKVersion%um;
%WindowsSdkDir%include\%WindowsSDKVersion%winrt;
%WindowsSdkDir%include\%WindowsSDKVersion%cppwinrt
LIB=%WindowsSdkDir%lib\%WindowsSDKVersion%um\%arch%
See Microsoft Docs and this blog post
The Windows 10 SDK does not include utilities which are instead shared source. For D3DX12, you can obtain the latest header from here
You may also want to look at DirectX Tool Kit for DX12, DirectXTex, and DirectXMesh
For historic and usability reasons, DirectXMath is part of the Windows 10 SDK, but you can also get the latest version from GitHub. The recent Windows 10 SDKs also include the HLSL compiler/D3DCompile API including both the older FXC.EXE and the new Shader Model 6 DXC.EXE.
You may also find the Visual Studio templates on directx-vs-templates useful.
I would suggest reverting to the previous build and flagging the issue in the Feedback Hub. Also, if you haven't already, run chkdsk before and after install, just in case.
Is there any compatibility matrix as to what Visual Studio Versions (Say, ranging 2005 - 2017) are compatible with which Windows SDK Versions?
Should any Windows SDK be fully compatible with "any" C++ compiler, or are the different Windows SDK versions bound to certain compiler versions?
For example(!), we have a legacy C++ application that is still compiled with VS2005. We found that we'd like to use GetDpiForMonitor from this application. But to use this function, would require to use the headers+libs from at least an SDK supporting Windows 8.1 (e.g. the 8.1 SDK headers at C:\Program Files (x86)\Windows Kits\8.1\Include\um)
Generally, should a developer expect to be able to switch to a newer Windows SDK version without upgrading his compiler / Visual Studio?
Please refrain from suggesting to upgrade VS: This question tries to establish what you should do when upgrading VS is not an option for now, but you want to use stuff from (and depend on) functionality only available in newer Windows (SDK) versions.
concerning the "compatibility matrix": I don't think anybody made the effort to up to create one, also I'm not sure if this is really needed.
Rule of thumb: those API headers don't change quite often, and when they do, they are usually pretty much backward compatible.
The tricky part may be to teach your older VS to get along with a new SDK, you may need to change the VC+ include/source/lib directories for your solution/project manually.
(if it complies & links in your old VS, you should be fine)
The F# 2.0 distribution had a version of FSharp.Core compiled for WindowsPhone 7.1/Silverlight 4, but F# 3.0 doesn't, and the portable version only supports Silverlight 5 or Windows Phone 8. Has anyone been able to compile a version of FSharp.Core for F# 3.0 targeting Silverlight 4 or Windows Phone 7.1 from source? What are the defines required?
Edit:
On the fsharp compiler github repo, there's a target named portable-net4+sl4+wp71+win8, but in reality that's portable class library Profile47, which supposedly only support .NET 4.5, Silverlight 5.0 and Windows Store apps. It's the same as what's installed with VS2012. If you try to use it with a WP 7.1 project, it will fail at runtime complaining about missing IStructuralEquatable. It should really be named portable-net45+sl5+win8. There's a wp7 target also in the proj files, but it's currently not compiling
I managed to compile it, but since I don't normally use F#, I don't know how to test it. Have you followed the instructions for compiling? Just type the following commands in the VS Developer Prompt
cd src
msbuild fsharp-proto-build.proj
msbuild fsharp-library-build.proj
msbuild fsharp-compiler-build.proj
msbuild fsharp-library-build.proj /p:TargetFramework=portable-net4+sl4+wp71+win8
Note that I did it with Visual Studio 2012 Professional. If you want, I can send you compiled dll and you can try it.
Got both the wp7 target and Portable88 target compiling from F# source after a couple of changes https://github.com/ovatsus/fsharp
Still need to thoroughly test at runtime, though
Been trying for 2 hours now, and theres no luck. I wanna make it so I got templets for a win64 app (Not .net) but I can't find where to add platforms. Please help?
There is no "Win64" API. There are just 32-bit Win32 apps and 64-bit Win32 apps, and the only difference is a compiler/linker option which compiler/linker are used (different directory).
The Win32 templates work just fine for 64-bit development.
While (much) earlier versions of Visual C++ shipped with a private copy of SDK headers, VS2010 installs a version of the Windows SDK and uses an environment variable to find SDK headers during build. So installing a new SDK, as long as it updates your environment variables, is automatically found by Visual C++ projects at build-time. (With the old Visual C++ versions, the SDK installer was supposed to edit the tool paths in the Visual Studio section of the registry, which could occasionally fail)