Jump to content
  • Advertisement
Sign in to follow this  
dave

Is This A Good Approach?

This topic is 5176 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ok so im writing a general library of my own that will consist of things like classes that make quads and cubes etc. What i used to do is have the other classes that make up the engine, like the font (text writing class) and console to be able to ask the gen_qud class to make a quad. Then the Mesh or VB for the quad is retrieved from the quad class and used and rendered etc. Thats what i previously did and obviously its so slow, but a start. So what i want to do now is to have the quad class only provide the vertices for the quad and not make the mesh or VB. Then what i want to do is to have a render queue so that all the vertices created by calling the quad and cube classes are copied into one VB, then i an index through applying the textures etc. Now, im not sure how to do this. What i could do is have a linked list that would have an element for each quad or cube in the scene, and have a member of the linked list structure holding the vertices for that shape. Then go through the linked list each frame copying the vertices accross. Is Locking/Unlocking a VB say 10000 times a frame a bad idea? if not this means that i could render only 1 object at a time by copying that 1 object into the vb, then overwiriting with the next? any hints tips about this? ace

Share this post


Link to post
Share on other sites
Advertisement
You're copying an object one at a time into the VB and rendering it?
You'd be much better off building a scene cache of the vertices (eg: build up a store of the vertices in the current viewable frame) and sending them into the VB once (or twice) per frame.

Continously locking/unlocking the vertex buffer will slow it down, as will the several small memory copies into the VB.

Share this post


Link to post
Share on other sites
right so supposing the gen_quad function just setup an array of struct with the correct vertex data, copying that into the vertex buffer along with any other quads cubes and cylinders all in one go would be a fast way of doing it?

Share this post


Link to post
Share on other sites
Yes. Remember, you're generally trying to avoid locking/unlocking the VB as much as you can. In my DX game I used to fill an array as I went along and then dump this to the VB for rendering at the end of the frame. You could gain more performance by using IndexBuffers too.

Share this post


Link to post
Share on other sites
well once its filled what i want to do is be able to effectively render the each scene object with individual textures etc.

Share this post


Link to post
Share on other sites
Consider batching your vertices together by texture.

Imagine this scenario:

[This is a VB containing the following]

--Model A-- == Model B == -- Model A -- == Model B == -- Model A --

You change the texture state 4 times here. A->B (one change), B->A (one change), etc...

If you batch your scene buffering up by texture, you can reduce the number of state changes in your rrendering.

-- Model A -- -- Model A -- -- Model A -- == Model B == == Model B ==

You've moved from 4 state changes to just one - which will boost performance a lot if you're rendering a lot of models.

Your rendering loop would look like this:

- Fill VB buffer with vertex data
- Begin
- Change to Texture A
- Render Model A x 3
- Change Texture to B
- Render Model B x 2
- End
- Present

Share this post


Link to post
Share on other sites
What I do is build a mini model vertex buffer when I load the model - this is sat in system memory and is essentially a 'compiled' version of the model. What I do before the level begins is create a VB and copy across the cached model vertices to a level VB buffer. My rendering then uses the main VB as it's vertex source (using DrawPrimitive with either the raw VB or an IB) - this way you get little or no lock/unlock calls per frame, which would slow things down a lot. This would probably need chaging if low-level vertex manipulation was required on animated models, but for static models it works a treat. Again, I limit the number of state changes per frame too, so I'd render all models of one texture first from this VB and so on.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!