If I could have a nickel for every time a user has asked me “what machine do I have to buy so that I can max out all of the settings in X-Plane”…
The problem is simple and two-fold:
- X-Plane’s maximum rendering settings can sink even the biggest computers. Why is X-Plane’s maximum so “overbuilt”?
- The rendering settings are not good predictors of performance. Why the hell not?
The answers are, roughly in that order, “Because we can’t predict the future” and “because it has to be that way”. Here’s the situation…
The Maximum Limits
Some of X-Plane’s maximum settings are design limitations. For example, your anti-aliasing can’t exceed your card’s capabilities, and the visibility can’t exceed the loaded area of scenery.
Other limits are based on algorithmic limitations – there are as many objects in New York City as we could possibly pack in. We figure you can always turn down object density if there are too many.
Still other limits are based on guesses about hardware. We could have made the mesh or less complex – we chose a mesh complexity for the global scenery that we thought would be a reasonable compromise in frame-rate and quality for the v8 run based on typical hardware. This is just a judgement call.
So…how big of a computer do you need to run X-Plane with maximum objects? I have no idea! We honestly didn’t give it any consideration. Our strategy was:
- Make sure the maximum object density the renderer would produce would not exceed our disk space/DVD allocations. It didn’t…because objects are only in cities, they contribute only a tiny fraction to the size of global scenery.
- Make sure that we could turn object density up and down easily.
- Ship it!
We figure you’ll turn objects up and down until you get a compromise of frame-rate and visual quality that you can live with. If you can’t find a compromise, it’s time to buy a bigger computer, because we can’t give you something for nothing. All those objects require hardware to draw.
And I would go a step further and say it’s a good thing that the maximum density of objects is very high. When Randy (our sales/support/marketing guy) got a new PC, a very nice one, but not even the most ridiculous gaming box possible (and this was months ago) he reported that on the default settings he can fly the Grand Canyon at…283 fps!
My point is that the hardware keeps getting faster and we can’t predict where it will go. So it seems like a safe bet to leave the maximum settings very high for future users.
So How Insane is Insane
The other problem is that rendering settings don’t correspond well to machine power. I can’t tell you that a 3 ghz CPU can handle “tons” of objects. The problem is that hardware performance is a composite of a number of subsystems, and scenery complexity varies by region and even by view angle.
Even the slightest change in camera angle can have a pretty big effect on performance. Combine that with different types of scenery elements (objects in some, beaches in other, mountains in others) in different regions and it becomes very difficult to predict how well scenery wil work on a given computer.
A Good Value
Given all this, we don’t try to come up with correlations between the settings and the hardware. Instead we simply try to make X-Plane run as efficiently as we can, and try to verify that you get a “good value” – that is, a lot of graphic quality relative to the power of your computer. We have to trust that you’ll buy as much computer as you want and/or can afford, and we try to give you the best look we can for it.
So if you are shopping for a new computer, you can go for the “Rolls Royce” strategy, where cash is no object and you maximize every component (even if paying a huge premium for brand new technology) or you can go for a “good value” strategy, trying to find the best price-per-performance points.
I’ll close this off with a few tips on buying:
- If you are buying a new computer, be sure you have a PCIe 16x slot! Any decent motherboard should come with this — if it doesn’t, you’re not getting a good computer. A PCIe 16x slot for the grahpics card shouldn’t raise prices too much.
- Get 1 GB of memory minimum – X-Plane will run with less, but it helps, and memory isn’t that expensive these days. A new computer will be fast enough that the system can use the extra memory. I get my memory from Crucial – it’s good quality and often cheaper than what you pay if you let the computer manufacturer upgrade you.
- In the US for Windows/Linux, look for a graphics card between $100-$200 – that’s the best value range for graphics cards. Get an ATI or nVidia card (nVidia if you’re using Linux). I don’t buy my cards from PriceWatch but I find it a useful listing of the price point of a lot of graphics cards.
- Don’t get a video card with HyperMemory or TurboCache.
- Check the “suffix” of your graphics card on Wikipedia – there are tables for the clock speeds for both ATI and nVidia cards. An nVidia “GT” card will cost you more than an “LE” card, but will be clocked a lot faster and given you better performance.
X-Plane 860 uses GLSL pixel shaders. But this doesn’t mean you need any new hardware. It does mean you might need to update your drivers. Let’s break this down a little bit.
X-Plane never talks directly to your video card. It always talks to the video driver, a piece of software that acts as a translator between X-Plane and your video card. (That’s a gross simplification – video drivers do a lot of amazing things these days.)
Your video card has certain capabilities – different cards can do different tricks. The video driver tells X-Plane what tricks the video card can do.
So there are really four possibilities for any given trick:
- Your video card cannot do that trick. The video driver will tell X-Plane “I can’t do it.”
- Your video card can do that trick. The video driver will tell X-plane “I can do it”.
- Your video card can do the trick, but the driver is old and will tell X-Plane “I can’t do it” because the driver doesn’t realize what the card can do. (This can happen because the video driver you use might come with your operating system, before you bought the new video card.)
- Your video card cando the trick, but the driver has a bug. The driver will tell X-Plane “I can do it”, but when X-Plane says “go and do it”, the video driver will crash your whole computer. This happens when drivers are buggy and can usually be fixed by getting newer drivers.
Something to note about this last case – we only crash if X-Plane actually says “go and do it”. So when we release a new version of X-Plane that utilizes new video driver tricks…
- Some users have cards that can’t do it and will see no change.
- Some users have cards that can do it, so they see the new feature.
- Some users have cards that can do it but old drivers and see no change.
- Some users have buggy drivers and see a crash for the first time.
GLSL shaders is a certain way to use the pixel shaders built into some cards. (GLSL is an interface and language to talk to those shaders.)
GLSL shaders are definitely not required for X-Plane 860. If you don’t have them, X-Plane will run the way it always did.
But if your drivers are buggy and crash when GLSL shaders are used, you will need a software update to get good drivers. (There is a way out of this…if you really can’t get a driver fix, there are command-line options that will tell X-Plane “don’t use this feature even if the card has it”.)
Traditionally it always has been real memory – system RAM or VRAM – that’s been most important to the flying equation. But recently virtual memory has been a scarce resource. What happened?
To understand this situation, consider X-Plane 6 vs 8. Back in the X-Plane 6 days, a typical system might have 256 MB of system RAM, 16 MB of VRAM, and 2 GB of virtual memory* for X-Plane. That’s a ratio of 8:1 virtual to real RAM and 128:1 virtual to VRAM.
These ratios are actually pretty useful. At any given time only part of the loaded scenery is visible, so only part of it needs to be in real RAM/VRAM. So having that extra virtual memory lets us load a big chunk of scenery at a time, rather than having a lot of complex details to load tiny bits of scenery.
Today’s computers are a bit different. 2 GB of RAM is not uncommon…that’d be a ratio of 1:1! And most gamers cards have 256 MB of VRAM now for an 8:1 ratio with VRAM. 512 MB cards are coming out and nVidia’s monstrous 8800GTX comes with (gasp) 768 MB of VRAM! Insanity!
The problem is: RAM and VRAM are getting larger, but virtual memory is not! This means the ability to have the part of the scenery you don’t see in virtual memory is getting more and more difficult.
Why can’t we get more virtual memory? Well, the problem is to get more virtual memory we need 64-bit CPUs, 64-bit operating systems, 64-bit drivers, and 64-bit applications. That’s a lot of parts that all need to be 64 bit and means a full computer upgrade and motherboard upgrade. Of the 5 machines Apple sells right now, only one is 64-bit, so even some of today’s fastest machines aren’t 64 bit. That’s slow adoption.
So in the meantime we’re adjusting X-Plane’s strategy to deal with increasingly limited virtual memory. Back in X-Plane 6 it was acceptable to leave all objects their textures cached in virtual memory for later use (which sped up reloading of scenery).
X-Plane 860 (coming soon to a beta near you) will change this – unused textures and objects will be fully purged, which will hopefully address the problem of running out of virtual memory during long flights over lots of different custom scenery.
* 2 GB? Well, technically an application can have 4 GB of virtual memory, but the OS keeps some for itself. Some OSes take 2 and leave 2, some take 1 and leave 3, but even if we had all 4 GB of virtual memory for application use (and we don’t – the graphics driver steals some too) we’ll have 4 GB machines soon, so virtual memory is disappearing.
Now that I’ve covered how to use X-Plane with command-line options and how to write up performance bugs, we can discuss the framerate test, why it exists, who should use it, etc.
The X-Plane built-in framerate test serves three purposes:
- To let us compare our current performance to past performance easily (so we can detect code that hurts sim performance early in our development cycle). This also lets us rapidly determine whether bug reports of “my framerate sucks” are valid or not.
- To allow graphics-card driver writers to use X-Plane to benchmark and regress changes to their drivers.
- To give us an easy way to get “hard numbers” in-field – that is, when a user emails us with a tech support request saying “my sim is slow”, the fps test allows us to determine whether the problem is based on configuration.
I’ve spent a lot of time in the X-Plane 850 release cycle looking at performance, both with the help of users (e.g. instructing users on how to look at their own machines) and my own. For all the complaining I’ve done I must say: THANK YOU to all of the users who have helped with performance analysis. These users put in a lot of hours doing mundane test after test and they did a great job of emailing me back information, fps reports, screenshots, and even a Shark profile or two! Even when the result is “hrm – everything is normal”, this kind of information is valuable in helping us prove that our release is solid. (And all of the indications I’ve found indicate that 850 is solid.)
But the process was very time consuming and error-prone. The frame-rate test simplifies things for everyone; the test is standardized and requires no user intervention; it runs the exact same settings every time and is not subject to software configuration issues. The reports are automatically printed out and require no observation.
We are adding the test into 850 so that in the next release we can compare to 850 and be sure we’re on track. I only wish we’d have the test in 840!
Should I Be Using the Framerate Test?
If you are not a developer/programmer and you are not asked to use the framerate test by a programmer (for example, in response to a bug report or after emailing tech support) there is no need for you to run the framerate test. You can run the test and email your friends (especially if you have higher framerate than they do) but if you have problems with the framerate test and you are using it “recreationally” please do not file a buf report or query tech support for help. The framerate test is an internal development tool; X-Plane is meant to be used to fly!
What the Test Does:
The framerate test runs X-Plane with preference reading/writing disabled, and it changes the ‘default’ configuration (e.g. X-Plane’s configuration without preferences) based on command-line input. This gives us a specific setup of the sim regardless of how the sim was last used. The preferences are not saved to disk when the test is done, so there is no need for a user to delete preferences to get solid test numbers. User alerts are not shown (just logged) so that the test can be run from a shell script automatically. The sim logs info and quits when it finishes.
The performance test can run in two modes: analysis mode and pass-fail mode. In analysis mode, the sim is run in three 30-second tests: panel view, forward view, and forward-view paused. These three numbers help us tell the relative framerate loss due to the panel and the flight model. The fps-test is primarily aimed at the 3-d rendering engine, but on a CPU-limited machine the flight model can have a huge impact, and on a PCI/AGP bandwidth limited or VRAM-limited machine the panel can cause a noticable slowdown. (The panel also hurts if a machine is extremely blend/fill-rate limited, like a Rage 128, but you shouldn’t be using X-Plane 8 on a Rage 128!)
The pass-fail test runs a single test, paused with the panel to gauge pure framerate, and returns 0 or 1 (as a command-line shell app) to the calling script based on whether the sim passes a minimum framerate. The pass-fail test is designed for automated testing; you can put X-plane into a series of standardized tests and automatically send an email if the sim’s performance falls below a certain minimum.
How to Use the Framerate Test:
First, see my instructions on how to use X-Plane with a command-line option. In these examples I will simplify the X-Plane executable name; refer to the instructions for your specific operating system.
To run the frame-rate test, use this:
X-Plane --fps_test=2
Where the number is a fps-test “test number”. (I will explain the numbers in detail below.) This will run the 3-part analysis test and quit. You can add other command-line options as well; for example, to compare performance with and without VBOs you can do this:
X-Plane --fps_test=2 --no_vbos
(Side note: on fps-test 1 pass-fail I see 71 fps on my MacBook Pro with VBOs and 59 without. Turning off VBOs definitely hurts performance, so only users with serious driver bugs should be using the –no_vbos option.)
To run the pass-fail test, you add a second command-line option:
X-Plane --fps_test=3 --require_fps=20
This will run the pass-fail test and return a positive result if the frame-rate is at or above 20 fps. For example, you could write a test like this:
X-Plane --fps_test=2 --require_fps=20 || echo We were below 20 fps!
Test Numbers:
The framerate test number is up to 3 digits controlling various aspects of the sim:
- The ones digit can be 1-3 and selects the rendering settings; 1 = very low and 3 = very high. You can view the rendering settings while the fps test its running (it will ruin your test results of course to put up dialog boxes).
- The tens digit can be 0-6 and programs in a variety of weather and visibility conditions.
- The hundreds digit can access a few special features: 100-series tests use a far view angle and 200-series tests run at night.
We may invent more tests later on but this initial set lets us run the sim in a wide enough envelope to gather the data we need.
In a vain and foolish attempt to prove that I am the uber-nerd, I have configured my MacBook Pro to boot Mac OS X 10.4, Windows XP Home SP2, and Ubuntu Linux 6.06. It took a while to get everything set up, but all three now run X-Plane with hardware acceleration.
This provides a unique chance to compare the performance of the sim varying old operating-system factors (the OS, the drivers, and the compiler). The machine is a 2.16 ghz DuCore MacBook Pro with 2 GB of RAM and a 256 MB ATI X1600 card.
So without further delay, here are the numbers. Speed is in fps for frame-rate tests 1-3 (1 is lowest settings, 3 is very very aggressive). Each set of fps is for panel view, forward-no-HUD view, and the same view paused. Load times are in seconds for the KSBD demo DSF. The second load time is to reload the same scenery – the times are much faster on all 3 OSes because of the disk cache.
Drivers are not tweaked; this is simply the ATI binary drivers for Linux, whatever Apple ships in BootCamp (some 2.0 series ATI drivers) for Windows, and the 10.4.8 drivers for Mac, none tweaked in any way at the OS/control panel level. For Linux I disabled VBOs because they cause graphic corruption in some cases and slow frame-rate. This is probably a Linux/ATI driver bug.
PLATFORM Mac WIN LINUX
Load/Reload 2.77/1.31 5.02/1.33 3.05/1.04
FPS Test 1 65/71/80 64/69/88 56/62/62
FPS Test 2 49/55/54 50/56/56 34/37/37
FPS Test 3 15/15/15 16/16/16 4/4/4
Analysis:
- The Mac has the fastest disk performance; both Mac and Linux are significantly faster than Windows in raw loading. For reloading a file all operating systems are about the same, but it’s the load-without-cache case that counts.
- Windows has the highest frame-rates; slightly faster than Mac but quite a bit more than Linux. The lack of safe VBOs on Linux could account for this.
- In the case where the fps didn’t rise when the sim was paused, the limitation is with the video card – not surprising for tests 2 and 3 where there’s a lot of antialiasing, anisotropic filtering, and objects.
Tomorrow I’ll blog about how the fps test itself can be used.
I’ll hold off most of my comments until RC2 comes out; we thought it would be out a while ago but Austin had to go on a business trip. (So really this is RC3, because we’ve put more bug fixes in since RC2 almost came out but didn’t. Heck I have no idea what number Austin will give this build!) Anyway, new build should be out soon and then I’ll discuss some of the new features.
One thing I’ve looked at a lot over the last few days is anisotropic filtering. Basically anisotropic filtering is when the graphics card looks at more of a texture to make it look better when it is sloping away from the viewer.
X-Plane provides the graphics card with several versions of each texture in different sizes; depending on how far away the polygon is, the graphics card picks the right size for the best look. This is called mipmapping. It allows the graphics card to draw a very small version of a texture without having to do the work of scaling it down. Essentially the textures are pre-scaled to every possible size we could need. (But never bigger than the original size, modified by your texture resolution settings.)
The problem comes when a texture is sloping away from us. Consider when we are sitting on the runway at KSBD. The close part of the runway is just huge and requires the biggest version of the texture we have. The far end requires the smallest version. Anisotropic filtering allows the graphics card to look at extra data to preserve the details as the size it needs gets smaller. (I realize that that is probably the worst explanation of anisotropic filtering ever written, but I don’t want to get into the math…Google or Wikipedia to the rescue.)
Basically there are three things a user must know about anisotropic filtering:
- Anisotropic filtering makes a texture that is sloping away from us less blurry.
- The graphics card uses more texels (pixels from a texture) to render when it is on – 8x anisotropic filtering means the card can use 8x as many texels. That can really hurt framerate.
- What the card actually does is up to the hardware maker and driver writers. X-Plane just says “give me 4x” and hopes for the best.
Before X-Plane 850RC2 X-Plane only had a check-box…on or off. If anisotropic filtering was on, it was on maximum, which is an outrageous 16x for some cards! This gave you two options: a blurry world or a huge frame-rate hit.
Austin is working on complete anisotropic filtering control – that is, you can select the level of filtering from 1x to 16x, but with all the intermediate levels. The sim will default to 4x, which I’ve found is a good compromise of speed and image quality. So hopefully this will allow some users who had to leave anisotropic filtering off to get a little bit of filtering without a big frame-rate hit. I suggest you try changing the level on your computer and see what looks good and what is fast.
One thing I must admit: we’ve always had anisotropic filtering on the runways, and we will continue to always leave this on. It simply makes a huge visual difference in this one situation where we know that you will see our textures at a horrible viewing angle. X-Plane 850 RC2 is a little bit more polite than RC1 was; whereas RC1 and all previous versions maxed out anisotropic filtering on runways, RC2 will not increase it beyond 4x unless you set the rendering settings to do so.
One last mostly unrelated note: the high resolution earth orbit textures make the sim look nicer but hurt framerate. But they hurt framerate more if anisotropic filtering is higher. So this is a reason to carefully pick the amount of anisotropic filtering you want.
Previously I blogged that birds, planets cars and reflections all are new to 850 and eat fps. Here are some more ways we can lose framerate:
- If you compare your upgraded-to-850 full install against a quick download of the 840 demo, the comparison isn’t fair; it turns out that having full scenery installed is slower than having just one tile.
- The very nice demo KSBD layout Austin G. made us hits frame-rate a bit, with all of the lights, painted lines, and curved pavement.
What’s strange is the amount that these things affect the sim. One user reported a 30% loss to extra scenery and 50% loss to the KSBD layout. By comparison Austin’s layout is virtually “free” on my G5.
I am investigating ways to simplify complex airport layouts when settings are low. Regarding the fps loss when more scenery is installed, it turns out KSBD is relatively close to the edge of the DSF. So even though you can’t see water in the next tile (when you have the demo) it turns out a little bit is being drawn; X-Plane doesn’t know that the mountains hide this.
If you try this test while looking to the left (north into the center of the DSF) there is almost no difference between demo and full scenery.
This blog entry describes how to file a performance bug for X-Plane. You don’t have to participate in X-Plane betas, so if this procedure seems scary or too complex, I suggest simply waiting for the final sim release. But if you want to help, this procedure explains how to do it. It is not enough to just tell us “the framerate is bad now” – we will just ask for the information that this post explains how to provide.
First, to file a performance bug, you will need two clean copies of X-Plane: the current beta and the previous final release. Use the web-based installers to install clean copies of both of them. (Hint: you can download the current final release, then copy the folder and run the beta installer on the copy to save download time.) We always need a relative comparison of framerate between two versions to isolate how efficient the sim is from how fast your hardware is. If the sim is slow on your computer and has always been that way, that’s not really a problem with the sim. But if the sim used to be blazingly fast and now it is not, we can fix that.
In order to get a clean test we need to control every aspect of the simulator. Fortunately these clean installs have default preferences. But you will need to go through and make sure you have:
- The same weather settings!
- The same rendering settings. Make sure new features are off, e.g. if you are comparing 840 and 850, disable birds in 850.
- The same aircraft.
- The same number of AI aircraft.
- The same location.
- The camera facing in the exact same position and direction!
- The same view mode (e.g. forward, forward with panel, etc.).
For your framerate test you will basically run the sim in a fixed configuration and take some screenshots.
It is very important that the camera angle be fixed. Use the “takeoff” menu item to place the plane on a runway. Do not taxi the plane into position; even the slightest change in the positioning of the camera can have a large impact on framerate, so if there can be human error in moving the camera, then the comparison is not valid. By pre-placing the plane you can get the same camera angle every time.
Some important notes on screenshots:
- Control-period will take a screenshot in any screen, so you can take a screenshot of your weather settings, not just the sim screen. Always use control-period, not the built-in OS screenshot mechanism.
- Please send us the original PNG files in a big zip file; please do not crop, editor or compress them!
- Please do not run the sim at larger than 1024×1024 as the screenshots will be clipped.
For both 850 and 840 we will need three screenshots (so for each performance report we will need six screenshots):
- A screenshot of the sim running. Use the data outputs screen to view frame rate, plane latitude, longitude and altitude, and camera location on-screen, so that these are captured in the screenshot.
- A screenshot of your rendering settings.
- A screenshot of your weather settings.
These last two allow us to exactly copy what you have configured. Please do not use “real weather” when you do these tests.
For each performance report, please send us the six screenshots, the log.txt after quitting both versions of the sim (so two log.txt files) and please tell us in the email the framerates of each sim both when paused and unpaused. (Take the screenshot when unpaused.) So there will be four fps numbers to report for every given test.
Note that these clean installs will not have any third party add-ons; if your performance problem is only visible with a third party add-on, please:
- First do the performance test without them and file that pair of datapoints.
- Then install the add-on on both and make as few configuration changes as possible and then file that data too.
So for a third party bug there might be eight fps to report – all combinations of: old and new, paused and unpaused, clean and with the add-on.
I just finished answering a user’s questions about whether to upgrade from a Pentium D to a Core 2 Duo and now I am back looking at a framerate problem on a 1.4 ghz G4 with a Radeon 9200.
Let’s just consider that for a second!
One set of X-Plane users has the latest generation hardware and expects X-Plane to look as good as it can. Getting 270 fps on this hardware (yes, we have seen fps this high with the default settings) is not useful – these users want more graphics on their big machines. If we don’t give them this, X-Plane is not a competitive product.
Another set of users still has previous generation hardware. If I may single out a particular group – Mac users with the G4 processor – that previous generation wasn’t ever very impressive even when it was new. Basically Apple was stuck because the G5 was the best chip they had but couldn’t be built with low enough power to put in the places they wanted to put it. Apple also wasn’t putting terribly nice graphics cards in their machines at the time. (This was fixed when they stuck a 9700 mobility in the PowerBook.) So we have a whole group of PowerBook and Mac Mini users suffering from low framerate on older machines that were never that good as flight sim machines to begin with. (And G4 users I do understand your pain – until about a month ago my laptop was an 800 mhz G4 with a GeForce 4 MX.)
It is in this context that I say: if your framerate is low, be sure to turn the new stuff off! I did some extensive benchmarking of X-Plane 850 vs 840 and can tell you four things that very much affect framerate:
- Cars on the roads! Cars really kill framerate. 840 has no cars, so it wasn’t doing any of that work. Turn them off!
- Birds! 840 had no birds, and they represent more drawing. Birds really divide machines into the haves and have-not’s…big machines don’t even notice the cost, but if you are having framerate issues, turn them off.
- Textured lights with 3-d frames. This is one of the bigger hits. I will comment on this more below, but if you’re fighting for framerate, turn this off.
- Water reflections and shadows. This isn’t the perfect setting, because it requires turning off cloud shadows as well as water reflections, so try it last; water reflections are actually not that expensive but you may get a few fps back.
In my benchmarking my dual 1.8 ghz G5 with Radeon 9600 XT (this machine is significantlty slower than a new DuoCore MacBook Pro by the way, so this machine represents a lower performance point than ANY new hardware that anyone should buy for X-Plane) I found that with these 4 settings off (and the equivalent textured lights and water reflections off in 840) X-Plane 8.50 was consistently faster than 8.40. Turning on water reflections and textured lights (but not the 3-d cars and birds) makes 8.50 slower than 8.40 but only slightly.
A final note on textured lights with 3-d frames: there are two catagories of graphics cards:
- Graphics cards with pixel shaders. On these cards, if you turn off 3-d textured lights, we will still draw them with textures, because the card handles it, so you’re not losing any framerate for the nicer looking lights.
- Graphics cards without pixel shaders. On these cards, textured lights are done with the CPU, just like in 840. They’re slow, so they are turned off.
My point is this: the checkbox gives you the best look when on, and the best look while prioritizing for speed when off. So if your framerate is low, turn off the 3-d textured lights; we will give you any quality that we can give you for free and nothing more.
In summary: you can’t have a full bottle of wine and a drunken wife. If you want the new eye candy that was not present in the previous version of the sim (3-d birds, 3-d cars, water reflections and 3-d lights) you will have to pay for them with fps. We can give you the choice of fps or more eye candy, but not both.
A final thought: is it possible that 850 has a performance bug? Maybe! I am analyzing this now. I will post detailed instructions in my next blog entry on how to report these things. Filing a bug saying “the framerate sucks” doesn’t provide useful information; posting to a forum saying “the framerate sucks” doesn’t provide useful information either. But there are some tests you can do that will provide us with the info we need. Our biggest limitation is: we don’t have one of each kind of graphics card. So the 850 beta testers who have gotten us detailed performance numbers have been very helpful!
I just realized that the planet-wide rendering was running at 65 fps on my G5 with clear skies but less than 20 fps with a single cirrus layer! Ooops! With X-Plane 850 we use the same OpenGL code to draw terrain whether it’s close-up (DSF) or far away (the planet render). This seemed like a good idea because it helped the two mesh. Well, it turns out cloud shadows are way too slow when applied over a huge area.
So…I simply killed them. This will be in the next beta. If you look hard you’ll be able to see a slight color change (well, worse than before) where the cloud shadows disappear at the DSF->planet transtion, but the fps are worth it. The G5 went from less than 20 fps looking at the planet to 65 fps, and the MacBook Pro went from 36 fps to 100 fps.
This was never an issue in 840, where the planet had the simplest OpenGL code you can imagine and looked like, well, just compare the planet in 840 vs 850!
Anyway, this explains why I thought I’d fixed the planet code and users cried bloody murder: my standard framerate test has no weather, because that’s Austin’s code. (Hence I shut it off to check the performance of only my code.) But sure enough it was the weather that affected the “cost” of the planet render.
There is a moral here for programmers: always test performance under real-world conditions! Often a system can have interdependencies that don’t appear in “lab” conditions. (Another example: you can’t test the speed of airpor build-up without scenery because one of the slowest parts is “draping” the airports over the scenery. When there is no scenery the ocean terrain triangles are very large and so the draping happens much faster than it can with real ground.)
