D3dx9 11.dll For
Gaspard Xenos
Unfortunately, being a school system, I will need to package all DLLs not already installed so that it will run. Installing anything on the computers is out of the question. When I went down a few days ago I noticed that the application would not start up due to a missing d3dx9_43.dll file.
Earlier versions of D3DX did support static linking, but for reasons of security MS changed the rules to ban static linking. They wanted to be able to service these DLLs through WIndows Update and that's only possible if they are installed using the official redistributable package.
It's supposed to be done by including the DirectX 9.0 Redistributable package inside the application installer, but since you can't install anything you either have to ship all the dll with your executable (which is against the SDK license) or statically link against the DirectX runtime (which is also probably not allowed).
Statically link against the DirectX runtime is not a good idea and is not as trivial as it seems, I'm not even sure it's possibe but you must have to have the actual static libraries (not the one that are actually linked by themselves against the dll).
So the easiest solution would be to keep all the needed DLL with the exe, if you're worried about missing one dependency you can use the Dependency Walker. Note that this solution is not allowed by the SDK license and cannot be used to actually distribute an application to the final users.
So in my own personal renderer, I want it to be able to support D3D9 and D3D11. To do this, I thought about having a master renderer interface that two classes will derive from. One will implement the D3D9 renderer and the other will implement the D3D11 renderer. However, this requires that I statically link to both D3D9 and D3D11, which will (I think) require that both dlls be present at run time. Is there any way I can avoid this?
With Direct3D 11, a new paradigm is introduced called feature levels. A feature level is a well defined set of GPU functionality. For instance, the 9_1 feature level implements the functionality that was implemented in Microsoft Direct3D 9, which exposes the capabilities of shader models ps_2_x and vs_2_x, while the 11_0 feature level implements the functionality that was implemented in Direct3D 11.
It's not a stupid question at all, it's definitely something developers should look into if they wish to support direct3d 9 video devices. However, there are caveats. For example, if the dev wanted to run their application on Windows XP, they couldn't use the Direct3D 11 runtime because it won't work on XP.
Also, from personal experience, the D3D9 feature levels are a pain in the ass to work with. I've had several little "gotchas" when dealing with the D3D9 feature level (some of which have no or very sparse documentation) that I've nearly given up on caring if people can use it.
An example of one of the issues I ran into was copying a texture into a staging texture. Apparently, under feature level 9 you can't copy a resource into a staging resource if the source resource is in GPU memory and it's got a shader view attached to it. So, if you created a texture with a shader view, you're out of luck. So, create one without a shader view right? Unfortunately, no, that leads to another set of issues (e.g. you can't bind to a pixel shader, kinda necessary). There was that and a few other small issues I ran into (multi monitor was especially painful).
You could design a system to load your renderer dynamically as a DLL. This way the DLL would be the only thing linking to the libraries in question, your host application/API would have the interface abstracted so it wouldn't care about the dependencies. So, for example, you can detect whether the user is running XP and force load the D3D 9 renderer DLL, or if they're not then load the D3D 11 renderer DLL.
If you put both renderers in the same DLL then yes, you'll need to link against both. Whether the end user will require D3D11 and D3D9 installed to run, I can't answer with any degree of certainty because it's been an incredibly long time since I've dealt with that stuff, but I'm going to guess that yes they would require both.
You can statically link to d3d9.lib and d3d11.lib in the same project without problems (it's not recommended though). The d3d9.dll and d3d11.dll don't get loaded until you call Direct3DCreate9 or D3D11CreateDevice respectively (at least that's my understanding). Having the two dlls loaded at the same time shouldn't be a problem but you I would expect a storm of horrendously difficult to diagnose bugs to result from having a d3d9 device and a d3d11 device alive at the same time.
You have the right about creating a render interface that abstracts a d3d9 or d3d11 backend. Being able to switch between them at runtime is sort of a novelty that's not worth the effort in my opinion. I've never worked on a game that didn't simply build a separate exe for d3d9 and d3d11 distributions. My preference is to create multiple static libraries that implement the renderer interface in whatever API. The code in the actual exe project simply uses the render interface and is linked to the appropriate static lib at compile time based on a build configuration. Instantiating the appropriate renderer implementation is done with some #defines in your main.cpp or wherever else. The only problem with this setup is that you have to be vigilant about not injecting unnecessary #defines in other places and you end up with multiple exes.
As far as I know there's nothing inherently dangerous about having your app load both the D3D9 and D3D11 DLL's. I've been doing this for years since the PIX marker functions are exported from D3D9.DLL, and I don't believe it's been the cause of any problems. The old samples from the SDK also did the same thing.
As the others have already mentioned, there isn't any issue with linking to both statically. You can load your renderer as part of a DLL and selectively choose which one to load on which platform. You can even use them both at the exact same time in one application - I experimented with this back when D3D11 first came out: journal post.
Direct3D Books: Practical Rendering and Computation with Direct3D 11, Programming Vertex, Geometry, and Pixel Shaders
Articles: Dual-Paraboloid Mapping Article :: Parallax Occlusion Mapping Article (original):: Fast Silhouettes Article
You could design a system to load your renderer dynamically as a DLL. This way the DLL would be the only thing linking to the libraries in question, your host application/API would have the interface abstracted so it wouldn't care about the dependencies. So, for example, you can detect whether the user is running XP and force load the D3D 9 renderer DLL, or if they're not then load the D3D 11 renderer DLL.
I don't think I will want to use this because from what I've read, LoadLibrary and GetProcAddress don't really work well with C++ name mangling so I'll have to extern "C" a lot of things and I don't think that will work very well with namespaces. Although if I were to do this, what would be the best way to avoid rewriting declaration code (i.e. CreateDevice())? Should I just have a global header that doesn't belong to any specific visual studio project? Also, how would I load virtual functions from interfaces?
One solution I found on googling is, download the missing file and keep it in system folder and it will work. But is this the only solution? Why can't NFS work with the DirectX11 dll? I have d3dx9_32.dll and D3DX9_41.dll in my system32 directory.
Usually a game installs the version it needs, you also might want to check if it gave you the option to install DirectX during the game installation. You always want to do that, even if you already have DirectX installed, that will ensure that you have a version the game expects.
You also shouldn't just copy games from different computers, always use the installation routine. You're missing registry entries and other software the game needs that aren't in the game directory. Just copying a game fails very often to work, as you have seen now.
Trying to run Red Alert 3, keep getting an Invalid Licence, d3dx9_35.dll missing. Running Windows 10 (which I hear has issues with trying to get dx9 working properly sometimes.
I have tried installing DirectX from the Windows site and from the RA3 folder after it downloaded. No luck. I can run C&C 3 (after installing dx from it's folder) so I'm certain I do have d3dx9_35.dll, since I noticed it get installed while running DX installer from C&C3 folder.
If install dgvoodoo to game folder it shows error initialising directx.
if rename d3d9.dll to required dll, then error can't find point of procedure.
Is it possible to use dgvoodoo with this game?
WRC2 or WRC4 - have links only to d3dx9_43.dll and no links to d3d9.dll.
dgvoodoo logo shown, but game still works in SDR mode and AutoHDR feature not enabled.
Installing dgvoodoo only adds logo.
But, if the logo appears then the game is definitely rendered through D3D11/12.
dgVoodoo cannot hook D3D9 (or any other DX version) and tag their logo to the screen, all it can do is completely replace them with its own implementation.