Some notes on Performance:
On a strong system, it is unlikely that graphics is going to be the bottle-neck. FS9 may be complex and demanding on hardware, but it is also 8 years old now. Many of the techniques and styles used are outdated. With a fairly standard graphics card these days, FS9 is no issue. Instead, most performance bottle-necks are now more likely to be cpu related.
The avionics and systems-modelling are mostly achieved as gauge files. .gau are modified .dlls, which are themselves simplified executables. Dlls are modified to depend on outside input to function through the systematic stripping of some commands from the code. Gauges are similar, as they are complete programs depending on FS for data input and display output. Gauges run on the same cpu as the main game, being interpreted by the operating system as application extensions of the main executable, FS9.exe.
.XML and .cab gauges are not themselves much better than .gaus. .cabs must be unpacked, then interpreted into a format FS recognizes. Thus, in some ways, an .xml format gauge is more demanding on the system than a .gau. Complex .xml gauges are a real killer, as they depend on the loading and conversion of many bitmaps and coding files. All this conversion adds to the cpu load on your FS cpu.
CPU loading is a big issue, even so far from the creation of the game, because of the way that FS9 was built. 8 years ago, all CPUs were single core. Many of them were much slower than cpus now. FS2004 was designed with an optomistically-stated 450 MHz single-core cpu in mind! The state of the art has improved dramatically since then.
At first, cpus grew faster. My old machine had a single-core Celeron D clocked at 3.33 Ghz, overclockable to well over 5 GHz if I wanted to risk a melt-down. FS9 ran OK with that with 2 Gb RAM. Not optimal, but pretty good. Then, cpus grew broader. Multiple cores were introduced and multiple-threading was introduced to programming. Now, I have on my primary machine 4 cores clocked at 1.5 GHz each in my i5 cpu.
The problem, though, is that FS9 was programmed when there was no such thing as a multiple-core cpu! FS9 does not support multi-threading and cannot use more than 1.5 GHz on my cpu, even though 6 GHz are available to multi-threading applications! For FS9, that is a reduction of more than half from my previous machine! My graphics card runs the graphics much smoother, but complex aircraft still bring my system to it knees.
What can I do to free up my cpu?
In addition to doing such things as running AlaricityPC, setting the affinity of the program to a single core to disable the OS from slowing it by trying to speed it up, and running FS at a high cpu priority, I could simply avoid cpu heavy aircraft.
Or, as per a couple threads going in the FSX forum now, I could unpack all the .cabs so that FS doesn't need to bother doing that itself.
But, one thing I can do that has dramatically improved my FPS, is to simply decide how I'm going to fly! Do you fly from the 2d panel or from the VC? Once you know, you can strike at the core of the problem - excessive cpu usage.
You see, FS loads every gauge mentioned in the panel.cfg one time for every instance. It does NOT simply recycle the cpu and RAM space to display a gauge twice off of the same data! It also loads every gauge embedded in the .mdl file, too, so in a decently complex modern aircraft, it might have 100 gauges loaded, some of them two or three duplicate times! Each of these is a separate program, running on the same cpu as FS9 and using cpu time.
On some level, the fact that every gauge should be self-evident. This behavior can be observed in the sometimes disparate readout that can be observed between gauges in the 2d and VC panels. I know when Lionhearts Epic LT first came out, I had some trouble with that. I could do something in the VC and it wouldn't show up in the 2d panel and vice versa. I suspect that this is a symptom of the same behavior that FS98 used. Back in those days, for a multiple-engine aircraft, for instance, the engine gauges may have been repeated many times in the panel. If you inspected the gauge folder, you might notice that before running the program, there would be one gauge "engine.gau." After running a plane where "engine.gau" was used more than once, you might find "engine_001.gau," "engine_002.gau," "engine_003.gau," and so on, for every repeated instance of the gauge. FS created a duplicate for every repeat and used that duplicate as a separate gauge for processing purposes. After CFS1, that was phased out in preference of simply bunging the duplicate onto the RAM, but as my experience with the Epic LT illustrates, that method was not eliminated.
(BTW, the bug in the Epic LT of which I speak was present up to version 1.5. Now, at 1.9, the problem has long been fixed.)
For simple gauges, that doesn't prove much of an issue. Simple gauges don't have much to process. But, if you're running 5 copies of the same FMC or 6 copies of the same .xml-programmed terrain-mapping wizz-bang GPS unit, then you are eating a LOT of extra cpu time that could be used to run the simulation smoothly!
So, decide on your flying strategy and lets remove some of these duplicates...
For instance, I fly almost exclusively in the VC. Others use the 2d panel almost all of the time. Knowing this, I can eliminate excess cpu usage by eliminating extra gauge loading. I, using notepad, perform a little surgery in the panel.cfg file and delete all duplicate mentions of the gauges and skip the 2d panel view by inserting Doug Dawsons dsd_view_skip.gau into the VC.
Of course, if I want to use only the VC, I must be cautious. Some planes jam sophisticated system modelling only into the 2d panel. To retain systems, then I must retain the 2d panel view or the components of it that make the systems run as they do. If I fly only from the 2d panel, though, I can almost always delete the VC without thought. Most of the time, systems modelling is done by loading the gauges into the RAM memory through the first availble view, which is typically the 2d view. (It is possible to load systems through the VC view, but doing so would usually take reprogramming the panel.cfg in totality, but gauges can usually be left as they are in doing so.)
To sum it up: FS loads duplicate gauges for every instance they appear in the panel.cfg file. This drains cpu power. To regain FPS, delete the panel view you do not use, thereby removing duplicate loadings of the gauges and freeing cpu time for smooth running of the game. With care, this can be done without disrupting systems modelling or useablity of the plane.
This approach has done wonders for me. In many cases, I have gained 5-10 FPS per plane upon deleting duplicate gauge instances. On the really demanding ones, the improvement (without losing system fidelity or functionality!) has been as much as 15-20 FPS! That can mean the difference between a slide-show and smooth.
On a strong system, it is unlikely that graphics is going to be the bottle-neck. FS9 may be complex and demanding on hardware, but it is also 8 years old now. Many of the techniques and styles used are outdated. With a fairly standard graphics card these days, FS9 is no issue. Instead, most performance bottle-necks are now more likely to be cpu related.
The avionics and systems-modelling are mostly achieved as gauge files. .gau are modified .dlls, which are themselves simplified executables. Dlls are modified to depend on outside input to function through the systematic stripping of some commands from the code. Gauges are similar, as they are complete programs depending on FS for data input and display output. Gauges run on the same cpu as the main game, being interpreted by the operating system as application extensions of the main executable, FS9.exe.
.XML and .cab gauges are not themselves much better than .gaus. .cabs must be unpacked, then interpreted into a format FS recognizes. Thus, in some ways, an .xml format gauge is more demanding on the system than a .gau. Complex .xml gauges are a real killer, as they depend on the loading and conversion of many bitmaps and coding files. All this conversion adds to the cpu load on your FS cpu.
CPU loading is a big issue, even so far from the creation of the game, because of the way that FS9 was built. 8 years ago, all CPUs were single core. Many of them were much slower than cpus now. FS2004 was designed with an optomistically-stated 450 MHz single-core cpu in mind! The state of the art has improved dramatically since then.
At first, cpus grew faster. My old machine had a single-core Celeron D clocked at 3.33 Ghz, overclockable to well over 5 GHz if I wanted to risk a melt-down. FS9 ran OK with that with 2 Gb RAM. Not optimal, but pretty good. Then, cpus grew broader. Multiple cores were introduced and multiple-threading was introduced to programming. Now, I have on my primary machine 4 cores clocked at 1.5 GHz each in my i5 cpu.
The problem, though, is that FS9 was programmed when there was no such thing as a multiple-core cpu! FS9 does not support multi-threading and cannot use more than 1.5 GHz on my cpu, even though 6 GHz are available to multi-threading applications! For FS9, that is a reduction of more than half from my previous machine! My graphics card runs the graphics much smoother, but complex aircraft still bring my system to it knees.
What can I do to free up my cpu?
In addition to doing such things as running AlaricityPC, setting the affinity of the program to a single core to disable the OS from slowing it by trying to speed it up, and running FS at a high cpu priority, I could simply avoid cpu heavy aircraft.
Or, as per a couple threads going in the FSX forum now, I could unpack all the .cabs so that FS doesn't need to bother doing that itself.
But, one thing I can do that has dramatically improved my FPS, is to simply decide how I'm going to fly! Do you fly from the 2d panel or from the VC? Once you know, you can strike at the core of the problem - excessive cpu usage.
You see, FS loads every gauge mentioned in the panel.cfg one time for every instance. It does NOT simply recycle the cpu and RAM space to display a gauge twice off of the same data! It also loads every gauge embedded in the .mdl file, too, so in a decently complex modern aircraft, it might have 100 gauges loaded, some of them two or three duplicate times! Each of these is a separate program, running on the same cpu as FS9 and using cpu time.
On some level, the fact that every gauge should be self-evident. This behavior can be observed in the sometimes disparate readout that can be observed between gauges in the 2d and VC panels. I know when Lionhearts Epic LT first came out, I had some trouble with that. I could do something in the VC and it wouldn't show up in the 2d panel and vice versa. I suspect that this is a symptom of the same behavior that FS98 used. Back in those days, for a multiple-engine aircraft, for instance, the engine gauges may have been repeated many times in the panel. If you inspected the gauge folder, you might notice that before running the program, there would be one gauge "engine.gau." After running a plane where "engine.gau" was used more than once, you might find "engine_001.gau," "engine_002.gau," "engine_003.gau," and so on, for every repeated instance of the gauge. FS created a duplicate for every repeat and used that duplicate as a separate gauge for processing purposes. After CFS1, that was phased out in preference of simply bunging the duplicate onto the RAM, but as my experience with the Epic LT illustrates, that method was not eliminated.
(BTW, the bug in the Epic LT of which I speak was present up to version 1.5. Now, at 1.9, the problem has long been fixed.)
For simple gauges, that doesn't prove much of an issue. Simple gauges don't have much to process. But, if you're running 5 copies of the same FMC or 6 copies of the same .xml-programmed terrain-mapping wizz-bang GPS unit, then you are eating a LOT of extra cpu time that could be used to run the simulation smoothly!
So, decide on your flying strategy and lets remove some of these duplicates...
For instance, I fly almost exclusively in the VC. Others use the 2d panel almost all of the time. Knowing this, I can eliminate excess cpu usage by eliminating extra gauge loading. I, using notepad, perform a little surgery in the panel.cfg file and delete all duplicate mentions of the gauges and skip the 2d panel view by inserting Doug Dawsons dsd_view_skip.gau into the VC.
Of course, if I want to use only the VC, I must be cautious. Some planes jam sophisticated system modelling only into the 2d panel. To retain systems, then I must retain the 2d panel view or the components of it that make the systems run as they do. If I fly only from the 2d panel, though, I can almost always delete the VC without thought. Most of the time, systems modelling is done by loading the gauges into the RAM memory through the first availble view, which is typically the 2d view. (It is possible to load systems through the VC view, but doing so would usually take reprogramming the panel.cfg in totality, but gauges can usually be left as they are in doing so.)
To sum it up: FS loads duplicate gauges for every instance they appear in the panel.cfg file. This drains cpu power. To regain FPS, delete the panel view you do not use, thereby removing duplicate loadings of the gauges and freeing cpu time for smooth running of the game. With care, this can be done without disrupting systems modelling or useablity of the plane.
This approach has done wonders for me. In many cases, I have gained 5-10 FPS per plane upon deleting duplicate gauge instances. On the really demanding ones, the improvement (without losing system fidelity or functionality!) has been as much as 15-20 FPS! That can mean the difference between a slide-show and smooth.
