![]() |

As you may recall, I've been running FSX on my office computer. This machine has a 2 Ghz processor, 1 GB of memory and a decent graphics card. It's not a Ferrari, it's an SUV. Even so, it ought to be able to do a creditable job of running FSX. However, when last heard from, FSX was still stuttering, and still displaying minimal visuals, in spite of my initial elaborate disk defragmentation strategy. As I mentioned in Musings #2, I don't like it when a piece of software thinks it has defeated me, so as a background task I mulled over the whole situation for most of a day, determined to make the world safe for we flight simmers. Here's what I came came up with ...
Guided by software design experience I decided to see what would happen if I pushed all of the sliders all the way to the left instead of all the way to the right. The result? The graphics didn't look any different but, as I had hoped, the stuttering disappeared. (!) Here's what must be happening:
Case A: With the sliders all the way to the right, FSX brings into its scenery cache every conceivable detail of the visuals it thinks it's going to need over the next few seconds. However, since my office computer is "inadequate", FSX doesn't attempt to display everything that it imported. In fact, most of the information is sitting idle, pointlessly taking up space in the scenery cache and making it that much more difficult for FSX to get ahead of the aircraft in a scenery cache sense.
Case B: With the sliders all the way to the left FSX imports only minimal scenery details, and under these circumstances it is easy for the scenery cache to stay ahead of the aircraft.
In each case what gets displayed is the identical minimal visual detail, but in Case A the displayed information is accompanied by a lot of undisplayed excess baggage, clutter which crowds out the displayable information, resulting in stuttering. (We will say that FSX has a low "visuals to clutter ratio".) In Case B that excess baggage is absent -- never loaded -- so the scenery cache operates with maxiumum efficiency. As a result there is no stuttering in Case B.
There is another consideration: In both cases, to fetch a scenery file FSX has to work its way not only through the MFT but also through FSX's own set of indexes into its scenery and texture databases. These index searches take time and, as will be shown in Musings #4, this is actually the dominant issue for FSX performance.
Now please pay attention ... While rendering speed is a function mainly of CPU speed and graphics card throughput capacity, the ability to load data into the scenery cache stutter-free is a function mainly of hard drive speed and file system organization. In other words, what we want is file storage with the lowest possible access time and therefore the lowest possible index search times.
For FSX a fast 16 GB flash drive would work admirably, but we are years away from these being available, affordable and fast. In the meantime there are several fast external hard drives available for on the order of $100+ US. These drives offer average seek times of around 8.5 ms along with rotational speeds of 7200 rpm, specifications which are about twice as favorable as the ones I cited in Musings #2.
However, I must tell you that my office machine already has an internal hard drive with these same specifications, yet FSX still stutters in the Case A sliders configuration. To my knowledge there are no low-cost hard drives faster than mine so in order to be able to create FSX the developers must have had something else up their sleeves.
According to Microsoft that something else is the combination of 64-bit dual-core processors and the upcoming Windows Vista operating system, along with a new generation of DirectX. Without getting into details, with the cooperation of Vista, FSX probably is prepared to pass the job of loading its scenery cache to a second CPU. In addition, the potential exists for FSX to replace some of the historical FS extended precision integer arithmetic rendering-related calculations with new 64-bit floating point arithmetic. Such issues are danced around by ACES Studio spokesman Shawn Firminger in a recent FlightSim.Com interview.
So ... While I don't know how to cast runes or read animal entrails, my speculation about improved handling of the scenery cache probably is correct, though some of the improvement will come through exploitation of a second CPU rather than just through smarter file caching schemes. Therefore, because my office computer is 32-bit single-core, and because Vista was designed for 64-bit dual core, installing Vista RC1 on my office machine may not make much difference after all. We shall see.
After Vista is released we will want OEM machines whose component integration schemes have been designed specifically for dual-core operation with Vista, and we will want the hardware teething problems, probably cooling issues, to have been solved before we all run out and buy new computers like these. (Yes, I'm now actually planning to buy a new development computer.)
Thus we still have the question of how to get FSX to perform well on the computers we own today. This leads us back to the questions of defragmentation and file layout, subjects I will revisit in Musings #4. Armed with the insight that index search time is the critical issue for a given machine and operating system, we will also consider how best to set up FSX on today's computers.
So ... In the immortal words of The Crystals, FSX can be made to doo run run run, to doo run run. (Actually, it was Bette Midler who wrote that much-covered song as well as several other girl group hits.)
Mike McCarthy
Discuss This
in our Outer Marker (Feedback) Forum.
xxmikexx@qwest.net