Sometimes we find that users machines cannot run without hiding OpenGL driver features from X-Plane. That is, the computer says it can support VBOs, but when the sim asks for a VBO, something really bad happens. X-Plane (since mid-version 8) accepts a series of command-line options that cause the sim to ignore the given feature.
These kind of bugs come and go as drivers are updated, the sim changes which technology it uses, and hardware cycles through the user base. The biggest one we’re seeing right now is that the new iMacs show runway lights as white squares unless the sim is run with the –no_sprites option.
We’re trying a new way to address these problems. In the past we would give users the command-line option; now we are building double-clickable script files that launch the sim with the appropriate options. Theoretically this…
- Is less error prone for users.
- Is quicker for users who may have to use the command-line option every time they launch the sim until a driver update becomes available.
- Is quicker for us (in that we spend less time mailing out instructions and helping users who are unfamiliar with a command-line environment).
We did consider some other options, but this seemed like the least evil. The runners-up:
- Just turning off the hardware feature permanently. We ruled this out because the performance hit would be significant and affect all users.
- Attempt to identify and auto-turn-off known bad options. We do this in some cases, but it requires changes to the sim code, so this does no good if a new video card comes out after a given x-plane release and introduces new problems. so it’s not a total solution. Also since a bug might be resolved in-field, if X-Plane auto-avoids certain configurations we have to patch the sim once the configuration starts to work again.
- Provide a user interface to turn these options off inside the sim. This was ruled out for two reasons: first, some of these options cause the sim to crash before a user can ever get to the rendering settings. Second, turning off these kinds of options can really kill performance, so leaving the options in sight produces a whole new tech support option. (A user tells us their framerate is awful at the lowest settings…perhaps they turned off the hardware acceleration options in an attempt to get the lowest settings…etc.)
We’ll see how well this approach works. So far it seems to be working better than handing out command-line options.
(Of course if we can address the problem by working around it with a change to our code, we almost always choose this option.)
