Jump to content
  • Advertisement
Sign in to follow this  
Brian Lawson

Assigning/Linking textures and samplers to specific slots in technique declaration

This topic is 4397 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

From my understanding, it's perfectly valid to assign texture and samplers to specific texture and sampler slots from within the technique 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 these textures and samplers via the traditional way:
pDevice->SetTexture( nSlotID, SomeRenderStateID, SomeRenderState );
pDevice->SetSamplerState( nSlotID, SomeRenderStateID, SomeRenderState);

Rather than pEffect->SetTexture( "TextureName", pTexture );

However, the HLSL compiler does not seem to be honoring my request to bind these samplers to the sampler register I've specified. For example, I specifically requested that the BaseMapSampler be bound to Sampler[ 6 ], yet the HLSL compiler decided it was going to bind it to sampler register s0 (see below). Is this acceptable output, is it a bug, or is there some intermediate linkage going on that I don't know about, that properly hooks up sampler 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

    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]

Share this post

Link to post
Share on other sites
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.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!