I'm running on Win7 pro using MSVS 2010 Pro. I've started with DX10 and C++, but have come across multiple references to using DX11 or DX9. In essence... I've already spent 2 months learning DX10; I don't want to waste time on this version if I should migrate (I'm not worried about supporting Win8).
I appreciate any feedback.
The concepts will migrate easily. The math and theory are directly applicable. It is only the source code and the version specific details that need to be changed.
At the learning stage (and as this is For Beginners) it really doesn't matter which version you use. Learn the concepts of the pipeline, learn the mechanics of manipulating the data. Those are the important, transferable parts.
In a corporate world there will be a decision by senior team members and management to target specific age of computers, so you'll pick your interfaces based on compatibility and feature requirements. For now, just pick whatever works for you. If DX10 works for you, use it as long as you want.
Thank you Frob, for the timely reply. I was looking at the article Animating Characters with DirectX and saw that he was using DX9 as of April of this year. That was the main reason I felt compelled to ask.
Okay... DirectX 11, here I come. I removed the DirectX SDK (June 2010), as well as all other SDKs and VS2010 Pro for a clean environment. I've installed the Windows 8.1 SDK and VS2013 Express onto my Win 7/x64 machine.
However, I am unsure of proper linking in project properties. Which path should I link to if I don't want to worry about legacy, but can still run my program on my win 7 machine?
VS2013 Express should, by default, provide the proper search paths for most includes and librarys when you create new solutions from the menu. The default macro values, for instance, for $(WindowsSDK_IncludePath) should be (something like) ...ProgramFiles(x86)\Windows Kits\8.1\Include\um; ... etc., so you shouldn't really have to worry about it. Just do the "standard" #include <d3d11.h>, and link to d3d11.lib in the project properties. The default search paths for most headers and libraries (as mentioned) will be taken care of.
The docs will tell you (usually at the bottom of a page describing a function or class) which header to include, and which lib to link to.
FYI, keeping the June 2010 sdk around shouldn't be a problem, either. I keep it for some of my older DX9 projects ("old" as of a couple of months ago when I moved to D3D11) which I still play with. Avoiding "legacy" problems shouldn't be a concern, either. Unless you want to use something from the DirectX SDK, just don't set an include or library search path to it.
Thank you, Buckeye. I'll keep that in mind once I get DX11 working smoothly.FYI, keeping the June 2010 sdk around shouldn't be a problem, either. I keep it for some of my older DX9 projects ("old" as of a couple of months ago when I moved to D3D11) which I still play with. Avoiding "legacy" problems shouldn't be a concern, either. Unless you want to use something from the DirectX SDK, just don't set an include or library search path to it.
A big reason for my migration was hearing of all sorts of stuff from earlier versions disappearing into obscure regions of DX11; such as searching for tutorials on sprites and learning that now its best to use the XTK. I want sprites for UI because they always face the camera... unless they've changed that too.
all sorts of stuff from earlier versions disappearing into obscure regions of DX11
Actually, much of the "stuff" (ID3DXSprite, D3DXVECTOR, D3DXMATRIX, etc.) is no longer supported at all in D3D11. You have to do it yourself, or use a library such as the DXTK (which for beginners is preferable to implementing your own classes/structures.)
I want sprites for UI because they always face the camera
Just for clarification, a "sprite" is commonly just a textured quad rendered in screen space. As such, it doesn't "face the camera." That is, rendering a sprite in that way doesn't consider the world-view-projection process at all. The shader passes vertices already defined in screen-space coordinates through to the rasterizer. For UI implementation, that's commonly done by rendering the sprite objects last with depth buffering disabled to ensure it's rendered over the background.
For platform games, however, it's often the case that sprites are used (ala Mario) with depth enabled and the character can appear to pass behind objects.
There is a technique for rendering 3D objects which face the camera called "billboarding." That can be done with or without depth buffering enabled, depending on the desired effect.
This was an excellent clarification. Thank you.
Just for clarification, a "sprite" is commonly just a textured quad rendered in screen space. As such, it doesn't "face the camera."
Just to be pedantic; none of the "*D3DX*" stuff was ever part of D3D, it was part of D3DX (a closed source utility library made by MS to make some D3D tasks easier to get started with). What's happened is that support for D3DX has been dropped, so there's not any new versions. Instead, we now have some open-source utility libraries filling the void. AFAIK, DXTK is open source but also officially endorsed (and worked on) by Microsoft.
It seems like Microsoft made things more difficult to work with DirectX from version 10 on. Is this the reason so many people are still programming for version 9.0c?
