Matt's Homepage

So, I am working on something that requires I programmatically know what’s in a DX11 shader file.  One of the cool things you can use to figure out how many constant buffers, get string names from position streams, etc – is the DirectX Shader Reflection system.  It gives you the ability to query a loaded shader blob for names/types/etc.  However, it’s not quite as straightforward as one might expect to use.  The docs were pretty incomplete up until the DX11 version.  But here’s the basics of the ID3D11ShaderReflection system:

1. Load your vertex/pixel shaders.  Get the actual shader blob – or extract it from the FX system if you used that.
2. Bind it to a shader reflection object using D3DReflect:
   

   pd3dDevice->CreatePixelShader( pPixelShaderBuffer->GetBufferPointer(), pPixelShaderBuffer->GetBufferSize(), g_pPSClassLinkage, &g_pPixelShader );
   ID3D11ShaderReflection* pReflector = NULL;
   D3DReflect( pPixelShaderBuffer->GetBufferPointer(), pPixelShaderBuffer->GetBufferSize(), IID_ID3D11ShaderReflection, (void**) &pReflector);

3. Query the reflection object for whatever constant buffer, input/output stream, or other info you want using the many methods available.  It’s a GREAT way to test your shaders at load time so you don’t get cryptic runtime errors later when you try to actually draw objects.

Now, the gotcha’s:

1. You must also include this:

   #include <D3DCompiler.h>

   Or you’ll get a compile error with D3DReflect() – despite the fact the official Microsoft docs seem to say you should (only) include:

   #include <D3DShader.h>

2. Finally, you MUST have the DirectX SDK include directory listed before the windows include directory in the Visual Studio compiler include directory list or you’ll get compile errors in D3DShader.h. This is apparently because the windows headers that come with Visual Studio actually have a few DX definitions in them that conflict with the DX SDK header definitions.  
   In Visual Studio, check: Tools/Options -> Project and Solutions -> VC++ Directories and make sure Windows SDK include & library paths appear AFTER DirectX include & library paths.  See here for the thread.

From the wayback machine…

I found a half-completed post on when I was first learning to program on the iPhone.  I think these things are all still valid…
So, I’ve embarked on an ambitious programming project.  One that is now 1/3 of the way complete (first third was the ‘heaviest lifting’ part of the project – took about a month of outsourced grunt work).  The next 1/3 involves programming an app on the iPhone/iTouch.  I thought that would be the easy part, but as it turns out – there is a substantial learning curve that one should be aware of before starting this endeavor.  Here are some of the learnings I’ve found so far after having just got the bare bones of my own app up and running.

1. Apple’s documentation is very robust – but frustratingly ‘useless’ at times.  They provide many very detailed and excellent vertical stacks of information.  Want to learn about pooled allocators?  They have a document that gives you all the information you could ever want.  But not in the context of how you’d actually use them – or why you hit various problems you hit.   You’ll find yourself sifting around from document to document trying to find out why your NSString object is throwing an exception when returning from a function – only to find the real reason is buried in the memory management section of the Cocoa programming guide – not anywhere near the NSString documentation or their samples. 
2. You need to learn Objective C and Cocoa. – and learn them in THAT order.  It’s annoying, but try to find a good Objective C book first.  There aren’t many of them.  There are lots of bad ones though.  Learn how to write a class, add functions with multiple calling parameters, how to make calls to classes, and how allocation works.  That last one is key.  Really spend time learning why:
   [[NSString alloc] init]
   is the right way to allocate and initialize an object and then learn why:
   NSString *s = [[NSString alloc] initFromString:@”hello”];
   [s appendString:@”this string now leaks”];
   leaks memory.  And how the autoAllocator pools work/don’t work.  This is all huge and the first biggest gotcha’s your get hit with right off the bat.
3. You’ll struggle to get even a 5 line program working at first.  Your first Objective C/Cocoa programs will be very painful.  The simplest things will feel like fighting a brick wall.  I tried to do a simple enum, and kept getting burned by an invalid class definition.  Wha?  The objective C compiler on the iPhone requires you typedef your enums and structs:
   enum newEnum { a, b, c, d }; (NOPE – will cause a compiler error in whatever line follows this definition)
   typedef enum { a, b, c, d } newEnum; (yes – works)
   Just millions of little things like that.  Again, logical if you put your old C/gcc hat on, but it’s been a bit since I last had that hat on and it had some dust on it…
4. The GUI IDE is great – if you do things they way THEY want them and only for straight-forward designs.  The interfaces for GUI controls holds very much like Win32/X programming philosophies, albeit the syntax is very different.  X Code comes with it’s own WYSIWYG GUI editor, but I found it very limited if you’re going to come up with any kind of innovative interface.  If you just want some standard buttons/etc – you’re probably fine.  But if you want to have some interesting scrolling effects/etc – you best be ready to spend another few days learning how the UI control systems work underneath and experimenting.  The built-in GUI editor reminds me of the old VS2005 GUI editor that you could drag-n-drop controls, compile, and you’d see the results.  If you want any dynamic elements – I haven’t found a way to do that using their gui editor.  And if you want to embed controls on scrolling panels and some other more modern effects – you’ll be tossing the GUI editor altogether.  Trouble is, you spend a good bit of time learning how the built-in GUI system works, find out it won’t do the thing you need without tons of digging through forums and ‘tricking’ the thing to do what you want, then give up and have to learn a bunch of NEW stuff when you give up and decide to just dynamically/hand-generate the controls yourself.  Frustrating.