Jump to content

  • Log In with Google      Sign In   
  • Create Account


CreateVertexBuffer vs SetFVF


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 amtri   Members   -  Reputation: 175

Like
0Likes
Like

Posted 20 June 2012 - 04:10 PM

Hello,

I need a clarification on the CreateVertexBuffer and the SetFVF functions.

The CreateVertexBuffer function takes as its 3rd argument a FVF value. The SetFVF function takes a FVF value as its single argument.

My question: do these always need to be the same? In other words, can I create a vertex buffer that allows for, say, XYZ coordinates, color, normals, and 2D textures, and yet call SetFVF with only XYZ coordinates and color?

I'm hoping the answer is "no", and that I'm able to use a single vertex buffer for multiple needs, using SetStreamSource to accomodate this. And, if that's the case, when I fill the buffer with only XYZ and color, do I pack the first 4 32-bit words with XYZ and color, or do I leave space for the normals as the vertex buffer was created with enough room for it?

Thanks.

Sponsor:

#2 mhagain   Crossbones+   -  Reputation: 7422

Like
0Likes
Like

Posted 20 June 2012 - 05:32 PM

Normally you'd create a vertex buffer with an FVF of 0, enabling you to use it with any FVF you wish. The only reason to specify an FVF for a vertex buffer is if you want to use the ancient ProcessVertices call (and you almost certainly don't).

Eventually you're going to want to move from FVF codes to VertexDeclarations too, where you'll often create a VertexDeclaration that can't even be matched to an FVF code, so you can see that the FVF code specified for a vertex buffer is not really relevant for 99.99999% of use cases.

Regarding your last question, there's no one answer. You might create your buffer with room for normals, you might create a second buffer containing only normals and bind that to a second stream (you'll need a VertexDeclaration for that though). You just have to judge it as best you can - and ask for advice if you're in doubt - on a case-by-case basis.

For easier creation of VertexDeclarations when starting out, look at the D3DXDeclaratorFromFVF call (and don't forget that a VertexDeclaration is also a COM object that you'll need to Release when you shut down!)

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#3 amtri   Members   -  Reputation: 175

Like
0Likes
Like

Posted 21 June 2012 - 08:53 AM

mhagain,

Once more, you came to my rescue. Thanks!

For the time being, I'll stick with FVF. But I need further clarification from you. If I set FVF to 0 when creating the vertex buffer, are you saying that the buffer can contain combinations of vertex types?

I assume that I would use the offset when calling SetStreamSource, then set the starting node to 0 when calling DrawPrimitive - since the vertex buffer has already been positioned to the proper location with the first call. Then I call SetFVF to match the currently running FVF setting to DrawPrimitive.

Is this the case?

#4 mhagain   Crossbones+   -  Reputation: 7422

Like
0Likes
Like

Posted 21 June 2012 - 10:16 AM

That sounds right to me.

The only thing to watch out for is that some old Intels may report that they don't support stream offset. They're both lying and telling the truth; they don't support it in hardware for sure, but they don't support any of the vertex pipeline in hardware either. With software vertex processing in place (which you will need to use if you want to run on one of these) it works Just Fine.

This isn't something you're likely to come across these days, but in case you do it can catch you out.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#5 amtri   Members   -  Reputation: 175

Like
0Likes
Like

Posted 21 June 2012 - 10:29 AM

I'm not going to worry about these very old Intels.

Thanks for the help. I'm about to make some important changes to my code that should make it much faster!




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS