Jump to content

  • Log In with Google      Sign In   
  • Create Account


[c++] trying to squeeze performance


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 Knight52   Members   -  Reputation: 171

Like
0Likes
Like

Posted 13 August 2012 - 05:35 AM

1. Terrain. Right now I'm using multiple quad primitives connected to each other. This way I can divide terrain into blocks and each block can have additional texture specific for that block. But I see in some tutorial that they use one indexed primitives to create terrain. How much performance boost should I expect if I choose to change from multiple quad primitives to single primitive?

2. .X model importer. I have the code from this example and modify a bit. It might not be the best, but it does the job. Recently I notice significant fps drop when many models is on the screen (I'm using View Frustum Cull) and I begin to think I need some change. Is there .X model importer I should use instead?

3. Updating the game state. If I choose to create a thread to specifically handle the "main loop update", will that increase some fps? Is there any problem I should expect?

4. Should I call sin/cos/tan/etc function once and store the result instead of calling those functions every time I need to use the result?

Sponsor:

#2 Radikalizm   Crossbones+   -  Reputation: 2825

Like
0Likes
Like

Posted 13 August 2012 - 05:45 AM

These are all very case-specific questions, and these can all be answered by doing thorough profiling

First of all ask yourself this: "Do I have any performance issues with my current implementations?"
If the answer to that question is no you should just leave it be and move on to something else, unneeded or premature optimization is asking for major headaches later on

If the answer is yes however you should try out the different suggested implementations and thoroughly profile them against your current implementations in many different use cases. Based on the statistical data you get from that you can make your decisions as to which implementation works best for you.

I gets all your texture budgets!


#3 turch   Members   -  Reputation: 590

Like
1Likes
Like

Posted 13 August 2012 - 07:45 AM

1. Terrain. Right now I'm using multiple quad primitives connected to each other. This way I can divide terrain into blocks and each block can have additional texture specific for that block. But I see in some tutorial that they use one indexed primitives to create terrain. How much performance boost should I expect if I choose to change from multiple quad primitives to single primitive?


If you mean that you have one draw call for each quad, then you can expect a huge performance boost from switching to one or a few draw calls for the terrain. You can expect similar performance from rendering 1 or 1,000 triangles with a draw call - the draw call itself is the expensive part so you want to minimize them.

4. Should I call sin/cos/tan/etc function once and store the result instead of calling those functions every time I need to use the result?


If you mean precalculating a table of sin/cos/tan values, that's generally unnecessary nowadays. If you mean you need the same result multiple times, then calculating the result once and saving it is generally considered good practise. There are rare times when one or the other would be much better, but in general it doesn't matter. If it is in a tight loop, definitely cache it.

Edited by turch, 13 August 2012 - 07:58 AM.


#4 Knight52   Members   -  Reputation: 171

Like
0Likes
Like

Posted 13 August 2012 - 08:55 AM

If you mean that you have one draw call for each quad, then you can expect a huge performance boost from switching to one or a few draw calls for the terrain.

You mean DrawIndexedPrimitive() or DrawPrimitive(), right? Is there any way I can still draw additional texture specific to each quad? If the performance boost is that good, I'll consider removing that feature anyway.

If it is in a tight loop, definitely cache it.

Can you describe what is caching you're talking about?

#5 turch   Members   -  Reputation: 590

Like
2Likes
Like

Posted 13 August 2012 - 09:41 AM


If you mean that you have one draw call for each quad, then you can expect a huge performance boost from switching to one or a few draw calls for the terrain.

You mean DrawIndexedPrimitive() or DrawPrimitive(), right? Is there any way I can still draw additional texture specific to each quad? If the performance boost is that good, I'll consider removing that feature anyway.


Yes, the first thing you should generally do is try to reduce those calls - which is why instancing is nice: instead of drawing 100 orcs with 100 draw calls, you draw 100 orcs with one draw call and save a ton of time.

Why do you need textures specific to a quad? You can definitely use multiple textures, but the way you do it depends on what you are trying to achieve.


If it is in a tight loop, definitely cache it.

Can you describe what is caching you're talking about?


Caching is simply saving a value for later. So instead of writing

while(/*whatever*/)
{
	total += sin(x);
}

you would write

float sinOfX = sin(x);

while(/*whatever*/)
{
	total += sinOfX;
}

Assuming that x doesn't change during the loop.




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