• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
amtri

CreateVertexBuffer vs SetFVF

4 posts in this topic

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.
0

Share this post


Link to post
Share on other sites
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!)
0

Share this post


Link to post
Share on other sites
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?
0

Share this post


Link to post
Share on other sites
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 [i]any [/i]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.
0

Share this post


Link to post
Share on other sites
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!
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0