//Effect file:
cbuffer PerFrame
{
float4x4 World;
float4x4 View;
float4x4 Projection;
};
//CPP code
BYTE *pData = new BYTE[1000] //assume the constant buffer use 1000 bytes;
ID3D10Buffer *pBuffer //assume already created to bind as constant buffer
...
//Fills the CPU copy of the constant buffer
//assume the location to be filled is obtained through the
//Shader reflection inteface
memcpy(&pData[0], &WorldMat, sizeof(D3DXMATRIX));
memcpy(&pData[16], &ViewMat, sizeof(D3DXMATRIX));
memcpy(&pData[32], &FooMat, sizeof(D3DXMATRIX));
//Update the Constant Buffer
D3DDevice->UpdateSubresource(pBuffer, 0, 0, pData, 0, 0);
...
//Set the constant buffer
pEffectConstantBuffer->SetConstantBuffer(pBuffer);
will DX10 automatically handles Constant Buffer?
Author
Hi, I am a bit lost in my understanding of constant buffer usage in DX10 HLSL. From the SDK examples, e.g Skinning10, I don't see the sample code manually maintaining a Constant Buffer and updating it. Is there any gains in manually handling the constant buffer? By manually handling I meant:
Is it better to handle such things manually? The skinning SDK sample just used:
pMatrixVariable->SetMatrix(&WorldMat) etc to update the constants in the constant buffer. Which is a more prefered way?
The samples tend to keep things simple thus they put everything into the default/global CB.
It is definitely good practice to partition constants into CB's yourself - you're adding valuable domain knowledge that the compiler/runtime cannot easily figure out itself. For a trivial app like a sample it probably won't matter, but for a more heavyweight application you could notice it...
hth
Jack
It is definitely good practice to partition constants into CB's yourself - you're adding valuable domain knowledge that the compiler/runtime cannot easily figure out itself. For a trivial app like a sample it probably won't matter, but for a more heavyweight application you could notice it...
hth
Jack
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
