Vertex Packing

yes, IMHO it´s very important.
If you´ve have a disordered vertex declaration
(not identical with your vertex struct) you´ve got
problems.
(i´ve got, using MDX)

Greetings *Los Brutalos*

In d3d9, no. You can build your decl in any order you want, and declare the parameter semantics in a shader in any order you want; the runtime will route elements to where they need to go. This is (marginally) useful if you want to use the same VB to render to two different shaders, each of which might use different components of the vertex data.

@rendertarget
Argl ... did i something wrong ??
I do not use semantics yet, cause noone was able to explain the advantages
of that to me ... ;)
Thanks. maybe the wrong answer from me will help me too.

You should definitely use input and output semantics in your shaders. It's self-documenting if nothing else, but also ensures things end up where they should.

@rendertarget:
Hmmm. this will explain the problems i´ve got it the first time
writing shaders.
But one question further more:
Are the names for the semantics of your free choice or are they boundes
to some DX stuff (fixed names) ?
Most of shader samples i seen use semantics like WORLD or
VIEW or something like tgis (wich makes sense at all) but am
i able to name them e.g. SANTA or CLAUSE ;) ?
(if i want to)

Quote:

Original post by LosBrutalos @rendertarget: Hmmm. this will explain the problems i´ve got it the first time writing shaders. But one question further more: Are the names for the semantics of your free choice or are they boundes to some DX stuff (fixed names) ? Most of shader samples i seen use semantics like WORLD or VIEW or something like tgis (wich makes sense at all) but am i able to name them e.g. SANTA or CLAUSE ;) ? (if i want to)

Input and output semantics -- those semantics you apply to input and output variables -- need to be the standard ones: POSITION, NORMAL, BLENDWEIGHT, COLOR, etc. This is how D3D knows where to map things. (Note that this is all HLSL.)

What I meant is the ordering of vertex elements, are the fixed or flexible just as long as the order match with the order of the vertex declaration. Can we just use vertex declaration for both fixed function pipeline and shaders and get rid of FVF altogether?

Yes you can. If you set a vertex declaration but no vertex shader Direct3d do a fallback to the fixed function pipeline and use the elements you have specified in your vertex declaration.

You have to make sure that your vertex declaration contains the right types and usages for your elements. This list should help you:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/Mapping_between_a_DirectX_9_Declaration_and_FVF_Codes.asp

So element order in the vertex structure doesn't matter as long as it conforms to the ordering of the vertex declaration? Because for FVF, say we have 3 floats for position and a DWORD for diffuse color, no matter what the position must be declared in the struct before the diffuse color.

As always with D3D9 It depends on different things.

There are many rules: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/Mapping_between_a_DirectX_9_Declaration_and_FVF_Codes.asp

As this all makes me crazy I am not using the fixed pipeline anymore. The number of cards that have hardware T&L but no vertex shader is already very limited. Migrate to shaders will ease your pain and gives you much more freedom.

Try:

struct Vertex
{
DWORD color;
FLOAT x, y, z;
}

with

D3DVERTEXELEMENT9 VE[] =
{
{ 0, 0, D3DDECLTYPE_D3DCOLOR, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_COLOR, 0 },
{ 0, sizeof(DWORD), D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0 },
D3DDECL_END()
};

It doesn't work. However,

struct Vertex
{
FLOAT x, y, z;
DWORD color;
}

works fine with the above vertex declaration or:

D3DVERTEXELEMENT9 VE[] =
{
{ 0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_POSITION, 0 },
{ 0, 3*sizeof(FLOAT), D3DDECLTYPE_D3DCOLOR, D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_COLOR, 0 },
D3DDECL_END()
};

is ok too. Vertex buffer is created with the FVF parameter as 0 and SetFVF is passed 0. I haven't try this with shader but it seems that the fixed function pipeline requires that the vertex struct order the elements according to predefined ordering scheme. In this case for position and diffuse color, position must goes first.

Can someone confirm me that this is right? Which I hope is wrong.

I am sorry I am post the wrong link. This is the right one: http://msdn.microsoft.com/library/en-us/directx9_c/Mapping_FVF_Codes_to_a_DirectX_9_Declaration.asp?frame=true

Pre-Direct3D 9 Drivers: The input declaration must be translatable to a valid FVF
Direct3D 9 Drivers without Shader Version 3 Support: The input declaration must be translatable to a valid FVF
Direct3D 9 Drivers with Shader Version 3 Support: Vertex elements can be in arbitrary order and can have any data types.

As long as you don’t have a card with shader model 3 support you are bound to valid FVF formats. That was the reason why I recommend to use vertex shaders.

Quote:

Original post by Demirug Pre-Direct3D 9 Drivers: The input declaration must be translatable to a valid FVF Direct3D 9 Drivers without Shader Version 3 Support: The input declaration must be translatable to a valid FVF

The docs really should qualify this. After all, even the fixed function pipeline (at least on ATI cards) had functionality which couldn't be expressed by FVF (tweening).

Also, all shader capable ATI cards (Radeon 8500 and up) have the D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET cap set, and this is also not FVF compatible.

So something is fishy about these docs.