Quote:Original post by trick
1) Is the above even true?

Yes. Setting a texture, shader or vertex buffer is one of the most costly operations you're likely to perform several during a frame. But don't let this govern your life: upping from three to ten texture changes per frame will not affect your frame-rate. However, a general increase by a factor of three will do some damage when each of several hundred entities is setting its own texture. For this reason, you should sort the geometry so that it is rendered roughly in groups sharing the same texture/shader.

Depending on what you read, you'll be told to optimise in different ways; usually incompatible ones. It takes a bit of experience to be able to strike a good balance, but with a little practice and careful thought, you should be able to render vertex-cache-optimised geometry in a render-state-change-friendly manner.

Quote:2) Given the option of looping through an array of objects once, assigning each texture as you go (possibly assigning a texture multiple times), or looping through the array multiple times, each looking for a specific texture (so that each texture is only applied once), which would be faster (and is it a significant difference)? I question this one due to the amount of if statements that could be taking place, depending on the size of the array and how many total textures you have.

Neither sounds great. The optimal solution would be to sort the array at load-time (and keep it sorted as it is modified) so that rendering it in one pass requires minimal state-changes.

Quote:3) How viable is it to have many "textures" on the same image, such that you apply a texture once, and just use various UV coords for your polygons? Or, a better question, would this be a good way to avoid the performance decrease of assigning textures? (ie: an image that contains many different smaller images, so you only apply that texture one time and each object knows which part of the texture it needs).

It's very viable. The technique is known as atlas-texturing. There are pros and cons. The pros are obvious, the cons less so. Notably, texture filtering will cause the textures to 'bleed' into one another at the edges. For this reason, you're strongly advised to leave a few pixels of 'gutter' between separate texture elements. Also, texture-clamping becomes near-useless when the edges of the polygons aren't mapped to the edges of the textures.

Another often-overlooked way of minimising texture changes is to use up as many texture levels as you have available to you. This can be a little bit of a pain, as hardware support varies, but if you consider that many recent cards have sixteen texture-levels, it's worth the investment.

Quote:If it matters, I am using VC++ 6.0, and DirectX9. Also, I hear a lot of talk about running a program though a profiler to find the biggest reasons for performance-decreases. Can anyone tell me where to find these profilers at?

The topic goes quite deep (see this page), but you can get the salient data without too much effort. Get hold of PIX (in the DirectX SDK) for profiling Direct3D calls, and, depending on your processor, Intel VTune or AMD CodeAnalyst will take care of general application- or system-wide profiling.

Admiral