Hm I don't think that is what's causing the seams though. It isn't that things line up incorrectly between the hemispheres, but rather that a line of "nothingness" (the depth clear value) end up around it. The most obvious cause I can imagine is that the texels at the very edge of the projected circle blend together with the cleared outside. Since the shadow map is circular there will always be this "invalid" outline, so that's where I was thinking that maybe you could try to project a bit beyond a hemisphere and then only sample the middle 95% or something, such that you get a more proper "clamping" behaviour at the edge texels.
Another thing I thought of just now is that perhaps it would be better (if more expensive) to perform the paraboloid space transform in the pixel shader instead of the vertex shader? I imagine there will be more edges in the vertex shader approach, especially if the geometry isn't that detailed. I'm not sure if it would fix this particular issue though but it could be worth a try.
One way to make sure that you use the right version is to not use an import lib at all, and instead manually call LoadLibrary/GetProcAddress to get a pointer to the function you want to use from d3dcompiler_47.dll.
Ah yes, that should work; there are only two functions being imported from there so should be an easy thing, thanks.
I probably should see about making the switch and look further into what that will entail in regards to older OS support one of these days though.
Hah, yeah I suppose I really should try for that sooner or later.
What's blocking you from making the move to the Windows SDK?
Mainly a somewhat large pre-existing codebase and laziness, but also the need to support Windows 7 and Vista. I'm not sure whether upgrading to the Windows SDK would affect that, though I do recall reading that this was more for Windows 8+ (ie DirectX 11.1 and above)? I may very well be wrong there though.
As your linked-to article says however:
Your application uses use XAudio2 and supports Windows 7 systems.
This would also be a problem. Not an insurmountible one though as I don't have that much audio functionality yet; it would probably be possible to change to another library without too much of a hassle.
The array texture is bound to register t3 and is named "gTex", while the sampler is named "gSampler" and bound to s0 so I guess those add up with the differences towards your output.
Version 43 of the compiler is pretty old now, the latest Windows SDK contains Version 47.
Yes I know, perhaps I should try to replace it. I've been using it since it's the version that is included with the DirectX SDK from February 2010 which is the one I'm using. I recall trying to upgrade to the June 2010 version gave me troubles about two years ago so I settled for downgrading. Is there any way to maybe just replace the HLSL compiler? It would appear it simply loads d3dx11_42.dll (yes I was wrong and it isn't even using version 43 ) at runtime so I guess I could take a newer version, rename it to that and drop it in my program's working directory. I'd rather not have to rename it though.
Based on personal experience do not rely on the offset parameters. Broken drivers, broken hardware; missmatching results across vendors. It's better to just apply the offset yourself to the UVs.
Hm, I see. Yes, I suppose that wouldn't be too big of a hassle; I did change it for that successfully and I guess I will stick to that in the future as well then. Thanks for pointing it out!