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.
CreateVertexBuffer vs SetFVF
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!)
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!)
Author
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?
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?
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.
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.
Author
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!
Thanks for the help. I'm about to make some important changes to my code that should make it much faster!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
