   Assigning/Linking textures and samplers to specific slots in technique declaration
  From my understanding, it's perfectly valid to assign texture andsamplers to specific texture and sampler slots from within thetechnique declaration as such:technique Foo{   pass P0   {  Texture[ 0 ] = (g_ShadowDepthBuffer0);  Texture[ 1 ] = (g_ShadowDepthBuffer1);  Texture[ 2 ] = (g_ShadowDepthBuffer2);  Texture[ 3 ] = (g_ShadowDepthBuffer3);  Texture[ 4 ] = (g_ShadowDepthBuffer4);  Texture[ 5 ] = (g_ShadowDepthBuffer5);  Sampler[ 0 ] = (ShadowDepthSampler0);  Sampler[ 1 ] = (ShadowDepthSampler1);  Sampler[ 2 ] = (ShadowDepthSampler2);  Sampler[ 3 ] = (ShadowDepthSampler3);  Sampler[ 4 ] = (ShadowDepthSampler4);  Sampler[ 5 ] = (ShadowDepthSampler5);  Texture[ 6 ] = (g_BaseMap);  Sampler[ 6 ] = (BaseMapSampler);...This allows you to set these textures and render states for thesetextures and samplers via the traditional way:pDevice->SetTexture( nSlotID, SomeRenderStateID, SomeRenderState );pDevice->SetSamplerState( nSlotID, SomeRenderStateID, SomeRenderState);etc.Rather than pEffect->SetTexture( "TextureName", pTexture );However, the HLSL compiler does not seem to be honoring my request tobind these samplers to the sampler register I've specified.  Forexample, I specifically requested that the BaseMapSampler be bound toSampler[ 6 ], yet the HLSL compiler decided it was going to bind it tosampler register s0 (see below).Is this acceptable output, is it a bug, or is there some intermediatelinkage going on that I don't know about, that properly hooks upsampler and texture registers to the C/C++ side of the API?asm {//// Generated by Microsoft (R) D3DX9 Shader Compiler 9.12.589.0000//// Parameters:////   sampler2D BaseMapSampler;//   sampler2D ShadowDepthSampler0;//   sampler2D ShadowDepthSampler1;//   sampler2D ShadowDepthSampler2;//   sampler2D ShadowDepthSampler3;//   sampler2D ShadowDepthSampler4;//   sampler2D ShadowDepthSampler5;//   float2 g_MaterialProperties;//   float g_fShadowIntensity;////// Registers:////   Name  Reg   Size//   -------------------- ----- ----//   g_fShadowIntensity   c0  1//   g_MaterialProperties c1  1//   BaseMapSampler  s0  1//   ShadowDepthSampler0  s1  1//   ShadowDepthSampler1  s2  1//   ShadowDepthSampler2  s3  1//   ShadowDepthSampler3  s4  1//   ShadowDepthSampler4  s5  1//   ShadowDepthSampler5  s6  1//    ps_2_0    def c2, 1, 0, 0, 0    dcl_pp t0.xyz    dcl_pp t1.xyz    dcl_pp t2.xyz    dcl_pp t3.xyz    dcl_pp t4.xyz    dcl_pp t5.xyz    dcl_pp t6.xy    dcl_2d s0    dcl_2d s1    dcl_2d s2    dcl_2d s3    dcl_2d s4    dcl_2d s5    dcl_2d s6 [Edited by - Brian Lawson on June 8, 2006 2:37:03 PM]
  Bueller?   ;  The register semantic is what your after I beleive:sampler Tex0: register(s0);   ;  In addition to the correct semantic provided by griffin, I vaguely remember there being a bug with it.  Using v0, v1, etc, which don't really make sense for samplers, works perfectly.  The compiler likely ignores the 'v' or 's' part and just uses the indices, but using 's' was somehow broken.  I think it was when when attempting to skip a sampler, or maybe declare them out of order.  This might be fixed in newer SDKs.I'd suggest trying with s first.  If you run into trouble, then try v.   