Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

It seems they completely ruined .fx file loading / parsing in D3D11.

In D3D9, loading an entire effect file was D3DXCreateEffectFromFile( .. ), and you got a ID3DXEffect9, which had great methods like SetTechnique and BeginPass, making it easy to load and execute a shader with multiple techniques.

Is this completely manual now in D3D11? The highest level functionality I can find is loading a SINGLE shader from an FX file using D3DX11CompileFromFile.

Does anyone know if there's an easier way to load FX files and choose a technique? With the level of functionality provided in D3D11 now, it seems like you're better off just writing .hlsl files and forgetting about the whole idea of Techniques.

share|improve this question
up vote 10 down vote accepted

The effect functionality was refactored. It's fundamentally the same set of operations, you just have more control over them -- similar to how the D3D10+ interface redesign does mostly the same stuff as the 9 API, but affords you a more direct model of the hardware or driver to work with. The cost of this change to you is more verbosity in your code; more steps you have to take (often with more parameters) to reach a similar result.

D3D11 no longer ships binaries for the Effect API; it was moved to separate library which is provided as source (in the SDK sample directory) and you must compile it yourself. This was done to help divorce the versioning of the effect API from the versioning of the D3D API itself, which is tied to the Windows SDK). It also lets interested parties optimize and customize the API for their needs, as appropriate.

The HLSL compiler is still part of the core API (d3dcompiler_XX.dll) and can be used to turn .fx or HLSL source into compiled bytecode. That in-memory bytecode can, in turn, be used to produce an effect from the Effects11 API.

share|improve this answer
Oh boy. How is that going to affect people wanting to move from D3D9 to 11, but using D3D11 with a D3D10 device? My graphics card isn't compatible with 11, I'll just be using D3D11 without its dedicated features. – ChrisC Sep 23 '11 at 18:14
It should have no impact on using downlevel devices via the 11 API... – Josh Petrie Sep 23 '11 at 18:18
Yeah, gruesome both ways – bobobobo Sep 24 '11 at 0:00
Now that I've worked with cbuffer in D3D11, I can understand why they took out string-based shader variable updates. An obsession with performance seems to have led to this. Its not that bad, but its not easy either. You even have to be careful how you pack they cbuffer struct (must be 16 byte aligned), and there are special packing rules (defaults to 4-byte aligned unless specified otherwise with packoffset). – bobobobo Sep 24 '11 at 21:37

I found the ID3D10Effect interface, which does it.

Not at all easy to find, and the D3D10/11 sample packages seem to avoid using it!!

share|improve this answer

It's very much worth noting that using .fx files may cause much more harm than good in D3D10+ - which is possibly at least part of the reason why they seem to be moving to deprecation city.

In particular you need to be highly careful about how you manage constant buffer updates. .fx files hide this from you, and make it so easy to severely impact on your performance. You most definitely do need to arrange your cbuffers as if you weren't using .fx files at all, and at that point a rather large part of the reason for using Effects has gone away.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.