Originally posted on fsinsider.com

 

Now that I have  burst peoples bubble on PerfBuckets and Procspeed on my blog ( http://blogs.msdn.com/ptaylor ), let’s talk some real tweaks, TEXTURE_BANDWIDTH_MULT and BUFFERPOOLS.

 

These are tweaks in the fsx.cfg file.  If you don’t know what that is, you probably don’t want to be using these.

 

TEXTURE_BANDWITH_MULT (EDIT:this is in DISPLAY, not GRAPHICS)

 

The mysterious sounding TEXTURE_BANDWITH_MULT is our first target.  This is a setting in the [DISPLAY] section of the file, formatted like this:

[DISPLAY]

TEXTURE_BANDWIDTH_MULT=n

 

Where n can range from 10 to some reasonable value that is related to your frame rate limit.

 

From Rafael Cintron, part of the FS Graphics and Terrain team, comes this description:

 

The TEXTURE_BANDWIDTH_MULT option in the Graphics section is the target frame rate use for calculating texture bandwidth.  The higher you set this value the more textures we will allocate and copy per frame to the graphics card.  The lower you set this value, the less we will allocate and copy up to a minimum limit.  As an example, the default rate in the “high” perf bucket setting is 40.  The lowest perf bucket setting is 10. 

 

Higher settings on this flag can cause stutters on frames where the terrain system has finished compositing lots of textures.  Lower settings can reduce stutters on busy frames and spread out the load across multiple frames

 

So thinking this thru, if the value you set is 40, and your frame rate limit is 30, then we will send 40/30 or 4/3 as much textures per frame.

 

Moving this value to 400, like I have seen some users post in the forums, is probably *not* what you want to do since that increases the texture load on the graphics card by 10x, eg 400/40 = 10x. And after talking about this to Raf, setting it to 0 is ignored and can be validated by setting it to 10 which should give no different results.

 

BUFFERPOOLS

 

The pedestrian sounding BUFFERPOOLS is a section of its own in the fsx.cfg file. There is a setting in there called Poolsize, as in

[BUFFERPOOLS]

Poolsize=n

Where n is the amount of bytes we will allocate for one pool of vertex and index buffers to store geometry.

 

Again from Raf:

In RTM, the default setting was 1MB (1000000).  The lower this number, the more pools the allocator will have to rummage through to find space for buffers and the more stutters you may have.  In Sp1, we raised the default to 4MB (4000000) and optimized the underlying algorithm for finding free buffers

 

So be careful here, making this smaller can hurt you, since searching for space takes time and can cause stutters, and making the number too large can waste space. 4-10m is probably the range to be thinking about using unless you have a very high memory graphics card (  >512 )

 

 

So there you go, some real tweaks to begin your weekend with!