Comments on: The X-Plane 850 Framerate Test

By: Benjamin Supnik

Benjamin Supnik — Fri, 22 Dec 2006 22:35:00 +0000

You are right that the fps test is susceptible to some factors beyond our control.

In the case of add-ons (plugins, drivers, removing the KSBD package, adding global scenery), and command line options, we can see all this from the log file, so with a log file rather than the numbers, this stuff is easily handled.

For driver settings, we can't tell from the log file that some settings might be overridden. However, we almost certainly would see a strange pattern of fps between multiple tests (e.g. if fps test 2 and 3 run at the same speed, you've probably forced FSAA in the driver).

*Cheers*
ben

By: Caravelle

Caravelle — Fri, 22 Dec 2006 21:02:00 +0000

"This gives us a specific setup of the sim regardless of how the sim was last used."

Not really, at least on Windows.
This test keeps and uses the last screen resolution, the last color depht and the last antialias set by user.
And another difference could disturb if the user had removed KSBD scenery or not.

By: Benjamin Supnik

Benjamin Supnik — Fri, 06 Oct 2006 10:24:00 +0000

A few thoughts on that…
– We’ve used command-line tests mainly for things where we need to induce changes before the sim has initialized OpenGL…so making these GUI features might make them inaccessible if we have a load-time driver bug.
– In the case of the fps test, similar principles apply – the fps test acts on the sim very early in te init time.
– The fps test is primarily geared at us and driver writers, so the command-line interface is top priority…I don’t expect users to have to use it a lot in normal use.

There actually are a lot of debugging variables inside X-Plane…grab the DataRefEditor plugin and pick “view art controls” or “view stats” to see all the private junk X-Plane posts. We have other plugins that let us execute special commands and remotely trigger profiling. I chose to use a plugin for this rather than bake it into X-Plane because:
– The dataref mechanism has zero overhead when not in use and is completely hidden when the plugin is not installed, so we can be sure it’s not interfering with users in any way. Thus we can leave it in the production system.
– We recycle the UI code I already wrote for dataref editing for plugin authors, which saved time.

So there’s always a trade-off with these things regarding both how much time we spend on the tools and who the target audience is.

By: Mike Ash

Mike Ash — Fri, 06 Oct 2006 09:59:00 +0000

Have you considered adding a basic GUI to this? All of our apps present a special debugging panel when started with the Option key held down which lets the user do things like enable logging and various other debugging features. I think that this would help make this more accessible to your users, particularly to people in the Mac world (where I work) where people aren’t always so comfortable mucking about at the CLI. This may well be more complexity than you want, but I can imagine it being helpful in the customer support case, and I thought I’d suggest it.