Re: d3dx9: Implement D3DXFVFFromDeclarator.

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: d3dx9: Implement D3DXFVFFromDeclarator.

Henri Verbeet
On 30 August 2010 23:07, Misha Koshelev <[hidden email]> wrote:
> Looking forward to (constructive) comments.
>
Why are colors and normals special? What use is hasPosition? What
happens when the source declaration has e.g. two color elements with
usage index 0, or two position elements? Note that the booleans are
redundant, you store that information in the FVF.


Reply | Threaded
Open this post in threaded view
|

Re: d3dx9: Implement D3DXFVFFromDeclarator.

misha680
Henri Verbeet wrote
On 30 August 2010 23:07, Misha Koshelev <misha680@gmail.com> wrote:
> Looking forward to (constructive) comments.
>
Why are colors and normals special? What use is hasPosition? What
happens when the source declaration has e.g. two color elements with
usage index 0, or two position elements? Note that the booleans are
redundant, you store that information in the FVF.

As you can see by the tests added, colors and normals have an ordering that is specifically constrained within the FVF.

To clarify, by saying that the booleans are redundant, do you mean to say that, say, if I have a normal element, I should iterate back through all declaration elements that have already been processed and check for a prior color element, and then return D3DERR_INVALIDCALL?

Again, for the case of two color elements or two normal elements, are you suggesting I do the same (iterate through all past elements)? Wouldn't, in this case, a boolean be more efficient?

hasPosition I apologize does not need to be there.

Just trying to clarify your points regarding your comments re booleans and specialty of colors and normals.

Thank you
Misha
Reply | Threaded
Open this post in threaded view
|

Re: d3dx9: Implement D3DXFVFFromDeclarator.

Henri Verbeet
On 31 August 2010 14:47, misha680 <[hidden email]> wrote:
> As you can see by the tests added, colors and normals have an ordering that
> is specifically constrained within the FVF.
>
Well yes, but I'd say that ordering should apply to *any* FVF element,
not just colors and normals. E.g., point size before position or
texture before color should be just as untranslatable.

> To clarify, by saying that the booleans are redundant, do you mean to say
> that, say, if I have a normal element, I should iterate back through all
> declaration elements that have already been processed and check for a prior
> color element, and then return D3DERR_INVALIDCALL?
>
No, but you can check "*fvf & D3DFVF_NORMAL" to see if you already
have a normal.


Reply | Threaded
Open this post in threaded view
|

Re: d3dx9: Implement D3DXFVFFromDeclarator.

misha680
On Tue, Aug 31, 2010 at 7:58 AM, Henri Verbeet <[hidden email]> wrote:
> On 31 August 2010 14:47, misha680 <[hidden email]> wrote:
>> As you can see by the tests added, colors and normals have an ordering that
>> is specifically constrained within the FVF.
>>
> Well yes, but I'd say that ordering should apply to *any* FVF element,
> not just colors and normals. E.g., point size before position or
> texture before color should be just as untranslatable.
Thank you. I was not aware of these constraints.

Is there, by any chance, a good place for this? I have been checking
the MSDN docs so far:
http://msdn.microsoft.com/en-us/library/bb147173%28VS.85%29.aspx
but at least upon my initial reads did not notice any such guidelines.

>
>> To clarify, by saying that the booleans are redundant, do you mean to say
>> that, say, if I have a normal element, I should iterate back through all
>> declaration elements that have already been processed and check for a prior
>> color element, and then return D3DERR_INVALIDCALL?
>>
> No, but you can check "*fvf & D3DFVF_NORMAL" to see if you already
> have a normal.
That is a great idea!

I honestly did not think of that at all. Thank you for the wonderful hint.

Misha


Reply | Threaded
Open this post in threaded view
|

Re: d3dx9: Implement D3DXFVFFromDeclarator.

Henri Verbeet
On 31 August 2010 18:16, Misha Koshelev <[hidden email]> wrote:

>> Well yes, but I'd say that ordering should apply to *any* FVF element,
>> not just colors and normals. E.g., point size before position or
>> texture before color should be just as untranslatable.
> Thank you. I was not aware of these constraints.
>
> Is there, by any chance, a good place for this? I have been checking
> the MSDN docs so far:
> http://msdn.microsoft.com/en-us/library/bb147173%28VS.85%29.aspx
> but at least upon my initial reads did not notice any such guidelines.
>
It's implied by the way FVFs work. (Think about it, "D3DFVF_XYZ |
D3DFVF_DIFFUSE | D3DFVF_PSIZE" for example describes a very specific
vertex buffer layout, if you translate a declaration to that, it
should better describe that exact same layout.)


Reply | Threaded
Open this post in threaded view
|

Re: d3dx9: Implement D3DXFVFFromDeclarator.

misha680
Henri Verbeet wrote
On 31 August 2010 18:16, Misha Koshelev <misha680@gmail.com> wrote:
>> Well yes, but I'd say that ordering should apply to *any* FVF element,
>> not just colors and normals. E.g., point size before position or
>> texture before color should be just as untranslatable.
> Thank you. I was not aware of these constraints.
>
> Is there, by any chance, a good place for this? I have been checking
> the MSDN docs so far:
> http://msdn.microsoft.com/en-us/library/bb147173%28VS.85%29.aspx
> but at least upon my initial reads did not notice any such guidelines.
>
It's implied by the way FVFs work. (Think about it, "D3DFVF_XYZ |
D3DFVF_DIFFUSE | D3DFVF_PSIZE" for example describes a very specific
vertex buffer layout, if you translate a declaration to that, it
should better describe that exact same layout.)
Thank you. I had to check a reference but I think I understand now.

http://www.xmission.com/~legalize/book/download/05-Modeling.pdf

pg. 168

"The vertex components are laid out in memory in the same order as the vertex components
listed in the table, starting with the position component.
#define D3DFVF_XYZ 0x002
#define D3DFVF_XYZRHW 0x004
#define D3DFVF_XYZB1 0x006
#define D3DFVF_XYZB2 0x008
#define D3DFVF_XYZB3 0x00a
#define D3DFVF_XYZB4 0x00c
#define D3DFVF_XYZB5 0x00e
#define D3DFVF_NORMAL 0x010
#define D3DFVF_PSIZE 0x020
#define D3DFVF_DIFFUSE 0x040
#define D3DFVF_SPECULAR 0x080
#define D3DFVF_TEX0 0x000
#define D3DFVF_TEX1 0x100
#define D3DFVF_TEX2 0x200
#define D3DFVF_TEX3 0x300
#define D3DFVF_TEX4 0x400
#define D3DFVF_TEX5 0x500
#define D3DFVF_TEX6 0x600
#define D3DFVF_TEX7 0x700
#define D3DFVF_TEX8 0x800
#define D3DFVF_LASTBETA_UBYTE4 0x1000
Every FVF must include a position with one of the D3DFVF XYZ, D3DFVF -
XYZRHW, D3DFVF XYZB1, D3DFVF XYZB2, D3DFVF XYZB3, D3DFVF XYZB4, or D3D-
FVF XYZB5. The remaining FVF flags are all optional."

D3DFVF_LASTBETA_D3DCOLOR is not present in the list above, but as, per
include/d3d9types.h:#define D3DFVF_LASTBETA_D3DCOLOR   0x8000
it is last, I assume it would also come last?

Thank you
Misha
Reply | Threaded
Open this post in threaded view
|

Re: d3dx9: Implement D3DXFVFFromDeclarator.

Henri Verbeet
On 31 August 2010 18:48, misha680 <[hidden email]> wrote:
> D3DFVF_LASTBETA_D3DCOLOR is not present in the list above, but as, per
> include/d3d9types.h:#define D3DFVF_LASTBETA_D3DCOLOR   0x8000
> it is last, I assume it would also come last?
>
The LASTBETA FVF flags don't add elements themselves, they modify the
D3DFVF_XYZBn ones. See also D3DXDeclaratorFromFVF() for reference.