CEGUI (Crazy Eddie's GUI) Forums

Hi ,
Can anyone help me do this ? I tried , read every tutorial or guide out there , but I seem to be stuck.
I have created a VS11 solution but it does not build fully. The parts that do not build are :
2>------ Build started: Project: CEGUIDirect3D11Renderer-0, Configuration: Debug Win32 ------
2> GeometryBuffer.cpp
2>C:\Programming\Projects\CeGui\Cegui082\cegui\include\CEGUI/RendererModules/Direct3D11/Renderer.h(63): fatal error C1083: Cannot open include file: 'd3dx11.h': No such file or directory
2> Renderer.cpp
2>C:\Programming\Projects\CeGui\Cegui082\cegui\include\CEGUI/RendererModules/Direct3D11/Renderer.h(63): fatal error C1083: Cannot open include file: 'd3dx11.h': No such file or directory
2> Texture.cpp
2>C:\Programming\Projects\CeGui\Cegui082\cegui\include\CEGUI/RendererModules/Direct3D11/Renderer.h(63): fatal error C1083: Cannot open include file: 'd3dx11.h': No such file or directory
2> TextureTarget.cpp
2>C:\Programming\Projects\CeGui\Cegui082\cegui\include\CEGUI/RendererModules/Direct3D11/Renderer.h(63): fatal error C1083: Cannot open include file: 'd3dx11.h': No such file or directory
2> ViewportTarget.cpp
2>C:\Programming\Projects\CeGui\Cegui082\cegui\include\CEGUI/RendererModules/Direct3D11/Renderer.h(63): fatal error C1083: Cannot open include file: 'd3dx11.h': No such file or directory
2> Generating Code...
3>------ Build started: Project: CEGUISampleFramework-0.8, Configuration: Debug Win32 ------
3> CEGuiD3D11BaseApplication.cpp
3>C:\Programming\Projects\CeGui\Cegui082\cegui\include\CEGUI/RendererModules/Direct3D11/Renderer.h(63): fatal error C1083: Cannot open include file: 'd3dx11.h': No such file or directory
3> DeviceReset_Direct3D11.cpp
3>C:\Programming\Projects\CeGui\Cegui082\cegui\include\CEGUI/RendererModules/Direct3D11/Renderer.h(63): fatal error C1083: Cannot open include file: 'd3dx11.h': No such file or directory
3> Generating Code...
4>------ Build started: Project: ALL_BUILD, Configuration: Debug Win32 ------
4> Build all projects
5>------ Skipped Build: Project: INSTALL, Configuration: Debug Win32 ------
5>Project not selected to build for this solution configuration
6>------ Skipped Build: Project: PACKAGE, Configuration: Debug Win32 ------
6>Project not selected to build for this solution configuration

Obviously it cannot find the d3dx11.h but from what I read , there is no way to get that on windows 8 ...
Maybe I also need to mention that I am not trying to use the WINRT api , just plain win32.

Thanks!

Why can't you install the D3D11 SDK for window 8? Where did you read that?

1. link from google: http://msdn.microsoft.com/en-us/library ... 85%29.aspx

Ident wrote:Why can't you install the D3D11 SDK for window 8? Where did you read that?

1. link from google: http://msdn.microsoft.com/en-us/library ... 85%29.aspx

What I meant was that you do not install it separately , I do have windows sdk installed , but still it does not find d3dx11.h.
I also followed the instructions at point 5 from the link you mention ... still no change.

Again, this is the topmost google result i got on my first search by just googling the issue you described: http://msdn.microsoft.com/en-us/library ... 85%29.aspx
Can you open this link on your computer?
There is a section called "Using DirectX SDK projects with Visual Studio" which is subdivided in enumerated subsections. If you scroll down further you will reach subsection "5". Read it carefully and completely. There is a section 5.b. that tells you exactly how to rename the include-files of D3D11 of CEGUI so that you can compile it on your system. Furthermore, it reminds you to add the specific directories to your project (either global dir in MSVS or set it specifically just for your project).
Does this help?

We have no authority over how microsoft names its proprietary rendering library's files. Therefore you have to fix this on your own manually, you can thank the Direct3D developers for that.

Ident wrote:We have no authority over how microsoft names its proprietary rendering library's files. Therefore you have to fix this on your own manually, you can thank the Direct3D developers for that.

If I might butt in here, this is not an issue of naming conventions. D3DX was a helper/utility library, separate from the DirectX core libraries. I say was because it was deprecated some time ago and should not be used in any production code. Arguably it should never have been used in production code since it wasn't part of the core; it's the kind of thing one makes tutorials and sample frameworks from.

In any case, I respectfully submit that it is actually your responsibility to divorce your code from the obsolete helper libs. Generally speaking it's best to stick with the core and not muck about with wrappers and helpers precisely because this is the kind of situation you can wind up in.

To the OP, you can actually still install the old-style DirectX SDK. The June 2010 release is the most current one you'll find since the separate SDK is itself also obsolete, now that it's simply part of the Windows SDK. Do be careful about mixing and matching bits of the two. You'll likely have to do a little surgery on whatever source is dependent on the deprecated D3DX helper lib.

SomeDude wrote:

Ident wrote:We have no authority over how microsoft names its proprietary rendering library's files. Therefore you have to fix this on your own manually, you can thank the Direct3D developers for that.

If I might butt in here, this is not an issue of naming conventions. [...]

First of all, I didn't write this renderer,it was provided by someone who was not part of the dev time, if I remember correctly. It's no problem that you butt in, I'm glad if you clear up any misinformation i might have unfortunately stated here. I was just a little annoyed at the OP's inability to just use google, which would have easily gotten him the info that he can install the June 2010 SDK, or using the windows SDK files as described in the link i posted.

Did i understand you right that the "d3dx11.h'" header is an outside-fo-core core header that should not have ever been used in our production code at all, even with the June 2010 SDK? In this case, may i ask you which header should have been used, so we can correct this?

I didn't mean to imply that any of this was your doing specifically and I apologize if my post came across that way.

D3DX is nothing more than a bag of convenient helpers and wrappers for common tasks in a DirectX application. Along with DXUT it was used as the framework for Microsoft samples & examples. It was also widely adopted for the bulk of non-MS instructional materials you'll find in the wild. You'd be hard-pressed to find a "How to program DirectX" book that doesn't lean on the library because it saves the authors from writing hundreds of lines of code. To be fair it is terribly convenient since it encompasses everything from math to loading resources. But since it's not part of the API proper it was always possible that it would be left by the wayside one day and marked deprecated. That has now come to pass.

Microsoft has replaced D3DX with other libs for which they make the source available. There's an MSDN blog that describes the retirement of D3DX and what it was replaced with, here: http://blogs.msdn.com/b/chuckw/archive/2013/08/21/living-without-d3dx.aspx

However, my recommendation is to shy away from such wrapper/helper libs. This is partially because they come and go, and partially because the implementation may do something that is incompatible with the way your project or engine works; memory and file use, etc. For example, the new helper/wrapper libs make liberal use of the STL and exceptions, and no one in their right mind compiles big games with exceptions enabled. In my opinion the best plan for long-term happiness is to roll those functions for yourself. Use the source of the new libs as a starting point but don't be dependent on anything that by definition is not part of the core API.

Dear,
I do realize that this question is not directly related to CEGUI framework itself but rather a renderer (the DirectX11 one). I also realize that you guys are providing all of this for free and you are very busy.
If you are kind to help me and respond however , please do so with the respect and understanding that people deserve. I am running windows 8.1 I cannot install directx sdk june 2010. It simply fails to install on this version of windows. However it does say on the page that you linked to that the windows sdk now includes directx sdk , so I re-installed that. However after I follow all the steps in there and the CEGUI build steps I am still presented with the same error... Can you confirm that you have seen cases like mine (windows 8.1 , VS2012 , CEGUI 0.82 DirectX11 Renderer) working ?

rayden2909 wrote:Dear,
I do realize that this question is not directly related to CEGUI framework itself but rather a renderer (the DirectX11 one). I also realize that you guys are providing all of this for free and you are very busy.
If you are kind to help me and respond however , please do so with the respect and understanding that people deserve. I am running windows 8.1 I cannot install directx sdk june 2010. It simply fails to install on this version of windows. However it does say on the page that you linked to that the windows sdk now includes directx sdk , so I re-installed that. However after I follow all the steps in there and the CEGUI build steps I am still presented with the same error... Can you confirm that you have seen cases like mine (windows 8.1 , VS2012 , CEGUI 0.82 DirectX11 Renderer) working ?

Is it this error you get? http://support.microsoft.com/kb/2728613
There is a solution attached, I hope it helps!

SomeDude wrote:However, my recommendation is to shy away from such wrapper/helper libs. This is partially because they come and go, and partially because the implementation may do something that is incompatible with the way your project or engine works; memory and file use, etc. For example, the new helper/wrapper libs make liberal use of the STL and exceptions, and no one in their right mind compiles big games with exceptions enabled. In my opinion the best plan for long-term happiness is to roll those functions for yourself. Use the source of the new libs as a starting point but don't be dependent on anything that by definition is not part of the core API.

If we are not to use the helpers libraries, how are we for example supposed to do something as basic as compiling and linking an hlsl shader? If i understand correctly the D3D compiler is distributed as one of these helpers and thus not "core". I noticed that each of these libraries have gone through many versions (usually a new version comes out with each new SDK package) and there can be big changes between the versions - which is a risk for libraries as ours. Based on that I agree that we should not use these libraries. Your suggestion would be to look at the source cofe of the Windows SDK versions of these libraries and incoporate that source code into our CEGUI D3D renderers - is this correct?

I am unfortunately not too familiar with DirectX / D3D so I am not sure how much sense my question makes. I have so far only used OpenGL exclusively for all my rendering/visualisation projects.

rayden2909 wrote: However it does say on the page that you linked to that the windows sdk now includes directx sdk , so I re-installed that. However after I follow all the steps in there and the CEGUI build steps I am still presented with the same error

Yeah, you're missing a key point here. DirectX is now integrated in the Windows SDK but D3DX is no longer part of DirectX. It's dead as of Windows 8. That's the issue you're having; or at least the original issue. You can't compile because the D3DX calls do not exist in the current API.

As long as you're compiling regular Windows software and not for the nonsense Metro/App Store target you can get away with installing the old, separate DirectX SDK which, with a little cleverness, will allow you to keep using D3DX. You'll be drawing include and lib files from both a dead version of DirectX and the current version, so be careful about setting up the paths. You want the current version of the include and lib paths to come first in the search order so that you get the right file versions. It might be easier to explicitly link to the relevant files.

The second problem is the one preventing you from installing the dead SDK. Hopefully the link Ident gave you will help you solve that problem. If not you'll have to to be more specific about how it fails to install. Any error messages the installer gave would be helpful.

Ident wrote:If we are not to use the helpers libraries, how are we for example supposed to do something as basic as compiling and linking an hlsl shader? If i understand correctly the D3D compiler is distributed as one of these helpers and thus not "core".

If runtime compilation of shaders is absolutely required then there are functions that replace the D3DX functions, such as this:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh446872%28v=vs.85%29.aspx

It's also worth noting that when you compile an HLSL shader you get p-code blobs. This is widely misunderstood about HLSL shaders. The object files output by the shader compiler are not machine-specific microcode. That doesn't happen until you actually invoke the back-end compile through the runtime & driver by calling ID3D11Device::CreateXXXShader (XXX being Vertex, Pixel, etc). So unless shader source is being created on the fly there's really no reason to compile them on the fly. I have no idea how this compares to OpenGL. MS talks a little about this here; scroll down to the part about build time vs runtime compilation:
http://blogs.msdn.com/b/chuckw/archive/2012/05/07/hlsl-fxc-and-d3dcompile.aspx

I noticed that each of these libraries have gone through many versions (usually a new version comes out with each new SDK package) and there can be big changes between the versions - which is a risk for libraries as ours. Based on that I agree that we should not use these libraries.

It's nightmarish.
http://www.vg247.com/2011/08/03/valve-engineer-explains-why-steam-keeps-installing-d3dx-files-with-each-game-download/

Your suggestion would be to look at the source code of the Windows SDK versions of these libraries and incorporate that source code into our CEGUI D3D renderers - is this correct? I am unfortunately not too familiar with DirectX / D3D so I am not sure how much sense my question makes. I have so far only used OpenGL exclusively for all my rendering/visualisation projects.

Your question makes perfect sense and I'm the one who needs to clarify.

With Windows 8 came a mess which revolved around the whole "Metro"/AppStore platform. Microsoft didn't just kill D3DX; they also told the amateur/small-team community that they were killing the C# DirectX game framework called XNA, and if they wanted to create games for "Metro" they would have to adopt C++ and use DirectX like big boys and girls. People cried and raged. People cried and raged even more because MS simultaneously pulled the plug on D3DX.

To soften the blow, new C++ helper libraries like DXTK and DXTex were created. The idea was people who used to lean on D3DX and XNA could just use these new libs as-is. And that is a possible solution. Is it the best one? I don't know. Those libs are created and maintained by some Microsoft people but not as an official part of DirectX. In fact I would argue that they're even less official than D3DX was because they're separate packages. At least D3DX came "in the box" so to speak. That difference should give one pause. We accept that anything could happen to DirectX itself when the version changes, but in this case we're talking about something that could die independently of the API version, just as D3DX did.

An alternative would be to use that source as a basis for your own solutions. That's what I meant earlier. For example, there's a nice DDS-format texture loader provided by one of those libs. Rather than just have a dependency on the lib, one could transplant the code to their own source and make whatever modifications might be necessary to make it fit in. That could be really minor surgery. In fact, in that specific case you would most likely keep the vast majority of the code as-is, perhaps just changing the interface and file-system interaction here and there. It all kinda' depends on the structure of your own code and how well their source blends in with the way you do such things.

I suppose you could also tell people to suck it up and install the dead DirectX SDK but I don't know how long that will remain a viable solution. It's already potentially problematic unless people are careful about how they set up the lib and header paths.

SomeDude wrote:

Ident wrote:An alternative would be to use that source as a basis for your own solutions. That's what I meant earlier. For example, there's a nice DDS-format texture loader provided by one of those libs. Rather than just have a dependency on the lib, one could transplant the code to their own source and make whatever modifications might be necessary to make it fit in. That could be really minor surgery. In fact, in that specific case you would most likely keep the vast majority of the code as-is, perhaps just changing the interface and file-system interaction here and there. It all kinda' depends on the structure of your own code and how well their source blends in with the way you do such things.

I suppose you could also tell people to suck it up and install the dead DirectX SDK but I don't know how long that will remain a viable solution. It's already potentially problematic unless people are careful about how they set up the lib and header paths.

I personally prefer this alternative approach. However, to use and modify this external source we would have to verify that the licensing allows this first. License is Ms-PL so it might be possible. We could of course just look at it and try to write our own code based on it - which would be the best solution overall. I am just afraid of the amount of code required for this to be written....
Also, wouldnt this again required some d3d headers to be included? if yes - then are these available in both the d3d june 2010 package and the windows SDK? (I have no idea what headers would be required for this approach overall)

This whole thing is a mess!

Ident wrote: We could of course just look at it and try to write our own code based on it - which would be the best solution overall.

That's probably how I should have phrased it instead of saying "transplant".

I am just afraid of the amount of code required for this to be written....

I just had a look through the cegui DX11 renderer and the answer is "potentially a lot".

The worst news is that the current renderer was built around the Effects framework, which was a high-level abstraction of the pipeline API. I say was because as part of D3DX, Effects is considered deprecated along with the rest. In its place you're meant to call on the low-level API yourself. That would mean the entire paradigm of "effects" with "techniques" and "passes" is gone and in its place you'd be setting buffers and states and doing shader reflection (if you do that) explicitly; basically a whole new renderer. However, recognizing that some people were depending on Effects, it seems Microsoft whipped up a new version that claims to exist independently of the rest of D3DX.
Blog post here: http://blogs.msdn.com/b/chuckw/archive/2012/10/24/effects-for-direct3d-11-update.aspx
Library home here:https://fx11.codeplex.com/

That would be the easiest way to solve the problem. This version of Effects should allow you to divorce yourself from the legacy, separate SDK and you can hold off on writing a whole new renderer until DirectX 12 ships some day.

Also, wouldnt this again required some d3d headers to be included? if yes - then are these available in both the d3d june 2010 package and the windows SDK? (I have no idea what headers would be required for this approach overall)

Yeah, there's no way around that. Anything touching DirectX 11 is going to have to include d3d11.h. But that's a "normal" dependency, meaning it's a dependency on DirectX itself and not some potentially transient, external library.

This whole thing is a mess!

It is a mess but it's a preventable one. My background is game development (Interplay, Atari, couple others over the years) and this is exactly why we never used stuff like D3DX or Effects. It's more work up front to use the low-level DirectX API directly but once it's done it's done. No rugs will be pulled out from under you. When the DirectX version itself changes you write a new renderer for that version, but in the meantime it doesn't matter what happens to frameworks, helpers, or utilities.

I've had this thread open in a tab in my browser for months, waiting until I would have time to work on D3D11.

SomeDude wrote:I just had a look through the cegui DX11 renderer and the answer is "potentially a lot".

The worst news is that the current renderer was built around the Effects framework, which was a high-level abstraction of the pipeline API.

I am working on the D3D11 renderer in default branch currently and managed to remove the whole effects library and I am confident I will manage to get the thing running soon without any dependencies except for the d3dcompiler and d3d11 libs. When comparing the effects library to core usage, I feel like it just brings useless overhead anyways, although admittedly it "feels" easier, but it barely saves work for our simplistic shaders.

I do now even more than ever consider D3D to be a horrible mess. OpenGL feels a lot cleaner and more consistent in its usage and I manage to do the same things with a lot of less code. Also it doesn't depend on ridiculous coding conventions and types that only Microsoft/Windows uses. Intellisense sometimes even gets overwhelmed with these functions and some stuff is just unreadable... I don't get why game developers seem to prefer D3D11. D3D might have been better than OpenGL before OpenGL 3 Core Profile existed but this is definitely not the case anymore. It is just a badly documented library with lots of clutter, undocumented error messages, 20 ways to do one things and weird types and conventions.

Anyways I will report back here once I am done with changing all the stuff. This will all be only happening to default branch btw. So it is not going into any Releases before 1.0 Release, whenever that one will happen (hopefulyl in a half year or so).

My background is game development (Interplay, Atari, couple others over the years) and this is exactly why we never used stuff like D3DX or Effects.

Interplay/Black Isle made some great games i enjoyed a lot, what projects did you work on there, if I may ask?

I managed to entirely remove the Effects library dependency. D3D11 on default branch is up and working without any dependencies except for d3d11. Good job me!