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?

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.

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?

[quote name='turch' timestamp='1344865552' post='4969059']
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.
[/quote]

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.

[quote name='turch' timestamp='1344865552' post='4969059']
If it is in a tight loop, definitely cache it.

Can you describe what is caching you're talking about?
[/quote]

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.