Jump to content
  • Advertisement
Sign in to follow this  
Alex Red

better Draw Directly or Process vertices...?

This topic is 4850 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

Hi guys... I am drawing some models in DX7, and modellers as usual did a lot of little things in such Models... Just to make an example, there may be a big main 'body' of the model and then about 200 little Items to be transformed and drawn round it... I am finding that such little items suck a lot of drawing time, I am drawing by indexed VB, and each call may be long as 5 uSec... 1mSec for a model whose total drawing time is about 1.7mSec... I am drawing directly from the VB, and so I am wondering... is it worth to use no more indexed drawing ( seems I can not process vertices in indexed mode ), use the ProcessVertices() funtion to make a whole VB full of these transformed little things, and then make a single big draw...? Did any1 has any info about time/rendering speed improvements...? or any better Idea...? tnx [R]ed

Share this post


Link to post
Share on other sites
Advertisement
ProcessVertices is always performed in software. It's useful is you are going to render the same thing over and over, with no changed camera, object positions, lights, or any other vertex processing. In this case you transform once, slowly in software, then draw over and over again. Of course, this never happens in 99.99% of games, and with the advent of hardware vertex processing, ProcessVertices() is pretty much useless.

It *may* also be useful, as you guessed, if you have lots of small objects to draw, as each draw call has quite a bit of overhead. In this case you can use ProcessVertices() to do all your transformations in software, and after that, you can stitch together the resulting buffers and send that to the card in one shot to draw. Using the destindex of ProcessVertices() can help speed things up, but eliminating the need to stitch together the buffers. Doing the transformations yourself *may* also be faster than using ProcessVertices, but once you start dealing with lights, fog, texture transforms, etc, you may just opt to use ProcessVertices() to keep things simpler for yourself.

Whether this is faster, and by how much, depends on the card, your app, the driver, your motherboard, etc. Also, ensure you disable the debug runtimes and make a Release build when doing performance tests. Software processing (which will be all you have in DX7) checks lots of things. I've seen an app jump from 1 FPS to 40 FPS by switching to the retail directx runtime.

So, in the end, it *may* be faster. The only way to tell for sure is to try it. Before you try, make sure it's even an issue by switching to the retail runtimes.

Share this post


Link to post
Share on other sites
Tnx...'Unnamed'...
yep... problems here in doing my transforms are that the VB is allocated in Video Memory... no acces, if not at slow speed, however I would be interested just in positional Transformations, so thinking about both application transformed or the DX one option...
Funny that, even if Software processed, the ProcessVertices() call request a D3DD pointer 'to be used to transform vertices'....

About retail...well... I always work in release...to have no final surprises, should this be enough for DX7 to use Retail Lib...?

tnx

[R]ed

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!