Skip navigation

(Updated 27/6/2014)

There is an old saying in American show business: “If you can make it in New York city, you can make it anywhere else.” For FSX performance testing, this may will be: “If you can fly the PC-21 at KSEA, you can fly any other aircraft anywhere else.” The combination of resource hungry add-on and extremely heavy default scenery are excellent for benchmarking changes to the FSX graphics configuration.

We use a relatively rigourous system for performance benchmarking. Our system includes a saved flight, rebooting for each individual test, and deleting the FSX shader cache before each test. Changing FSX settings via sliders in mid-flight will not give accurate results particularly over a longer flight or lots of changes. Using this procedure requires A LOT OF TIME, especially if starting from cfg scratch. But the outcome of the testing is more reliable so that fewer changes need be made in the long term.

Our tweaks in 5/2013 were primarily based on the JB school of FSX magic. We were mostly CPU bounds during graphics rendering and needed to allocate our system threads very carefully to get max visual quality. As mentioned in Part 1, these FSX settings from a year ago were not working very well after CPU upgrade. Overall performance, FPS, was better, but there were more visual artifacts, flashes, etc. In addition to the hardware changes, we also added Orbx FTX Global texture set, increasing overall texture size and quality.

We always start testing with a benchmark. This benchmark is:

  1. fresh FSX shader cache
  2. new, basic FSX.cfg with only HIGHMEMFIX=1 added
  3. basic FSX slider config (in this case, based on Orbx recommendations for FTX Global)
  4. reboot
  5. basic external graphics processing (in this case, based on PMDG recommendations)
  6. starting saved flight and running with monitoring tools
  7. establish flight circuit that will be used for all test flights (can be done with AFCS if desired)

ProcessorsBenchmarkBenchmark flight

KSEATestCircuitTest Circuit

The head priest of the SK school of FSX tweaks has correlated texture flashing and visual artifacts with GPU processor saturation. But, these quality problems can also happen when the FSX rendering system is saturating the CPU. The oversimplified explanation is that the CPU gets behind and cannot send renders to the GPU fast enough resulting in “whiteouts” in the visual field.

Reducing FSX CPU load can be done with almost all of the graphics sliders, but some have more of an effect than others. Autogen and AI levels are the most CPU intensive elements of the FSX rendering system. Changes in these settings have the greatest/quickest effect on CPU usage. We worked on these settings first. Our compromise is a little autogen to a moderate distance out and a minimum of AI traffic. We like a few boats but no cars for sure.

FSX menu 3Our detailed FSX menu config

Our AI and cloud settings give us a little room to increase density/volume on flights that would benefit from the extra detail.

Several test flights later, we had gotten the flashes down to 3-6 times per 15 minute flight over the heaviest part of Seattle. With autogen at the minimum we could tolerate, we had to resort to fsx.cfg tweaks. In particular, “SmallPartRejectRadius”, “Terrain_Max_Autogen_Trees_Per_Cell”, and “Texture_Bandwidth_Mult”.  As you can see, we were still working on reducing autogen CPU load. For a very good discussion of these and other cfg file tweaks, see FSXTimes but Tom Tsui.

The complete list of our fsx.cfg additions:






May-MayComparisonComparison shots

Finally, a video showing the (more or less) final results.

 Flying the Realair Lancair Legacy on the same circuit, at 220 KIAS and same FSX settings, yields 40-50% higher FPS.

%d bloggers like this: