The Fugue

So, I’m hacking up a sweet joystick file. I thought, “Hey wouldn’t it be nifty if I could make some buttons do different things if I’m pressing shift or control or something?” It’s a known fact of life that you can never have too many joystick buttons.

Well, yes you can do that. But, no you can’t. FlightGear itself lets you do that—you use the nasal function getprop("/devices/status/keyboard/shift"), for example. The only problem is that this doesn’t work when FlightGear is compiled to use GLUT (vs SDL).

Apparently the geniuses that wrote GLUT don’t believe that there is a way to get the state of a modifier key except in conjunction with another event (regular keypress, mouse event, etc.) Read the sickening truth right here, where the problem is brought up on the freeglut-developer list, the “reasoning” against it is presented, there is a swift and sure rebuttal, and then silence.

So, I’m going to have to figure out how to get FlightGear to compile and run with SDL on OS X (so far it has eluded me, but I’ve got a few more tricks to try).

TerraSync is a nice little utility included with FlightGear that downloads scenery on the fly. It works like a charm, but there’s one caveat. FlightGear wants the scenery right now and TerraSync needs to download it first, therefore the first time you start FlightGear in a new area (or “teleport” there), you won’t have scenery. TerraSync will be busily downloading it in the background, though, so you just restart FlightGear a minute later, et voilá! But starting FlightGear that first time is a waste of time, since it takes forever to parse its config files and do a bunch of other stuff before it even tries to get the scenery. So I wrote a little shell script to do the job quicker.

Incidentally, this is the script I use to start FlightGear. It starts TerraSync if it’s not already running:

#!/bin/sh
PORT=5500
FG_HOME=$HOME/.fgfs
FG_ROOT=/usr/local/share/FlightGear
TERRASYNC_DIR=$FG_HOME/Scenery
FG_SCENERY=$TERRASYNC_DIR:$FG_ROOT/Scenery

pgrep terrasync || \
nice terrasync -p $PORT -d $TERRASYNC_DIR >> $FG_HOME/terrasync.log &

/usr/local/bin/fgfs --atlas=socket,out,1,localhost,$PORT,udp $*

Good news! FlightGear version 0.3.11-pre1 builds
perfectly well on OS X (Tiger). The dependencies are plib and SimGear. You
should install plib via macports (the 1.8.4 upstream tarball fails to build,
CVS might fare better), then compile and install
SImGear version 0.3.11-pre1, then compile and
install FlightGear and grab the fgfs-base package and move it to
/usr/local/share/FlightGear.

MacFlightGear works too, version
0.9.10. It will probably have an 0.9.11 release sometime not long after the
release of 0.9.11 (if not sooner), because it would be hard to justify not
releasing it when FlightGear builds out of the box. You might like the
one-download no-build nifty-gui-launcher aspects of MacFlightGear. I don’t
because it messes with .fgfsrc and I like the consistency with Linux. But we
never said I was sane.

The players

X-Plane is touted as “the most thorough, flexible, and realistic flight
simulator available for personal computers, and is available for Mac, Windows,
and Linux platforms.” FlightGear is “an open-source, multi-platform,
cooperative flight simulator development project” and “the goal of the
FlightGear project is to create a sophisticated flight simulator framework for
use in research or academic environments, for the development and pursuit of
other interesting flight simulation ideas, and as an end-user application.”

As you can tell, the goals of the two projects are only partially intersecting.
However, both are cross-platform flight simulators aimed at being more
realistic that their (common) predecessors. And if you run linux, they are your
only real choices. So without further ado I will commence comparison.

Continue reading

I sincerely hope that I didn’t lead anyone astray with my recent posts knocking the Intel GMA 950 display adapter in the MacBook, based on my experience with FlightGear. While it’s a given that the display adapter is a low-end integrated chip, it’s not anywhere near as bad as I made it out to be.

I was uneasy with the conclusions I had drawn. Part of it was optimism and part
of it was probably instinct. It just didn’t add up.

The version of FlightGear I had was 0.9.9 as linked to by the FlightGear Homepage. 0.9.9 was old, and I was on a quest to get version 0.9.10. I was in the process of trying to get it compiled and ended up at http://macflightgear.sf.net. I had visited this site back a month or so ago and it hadn’t been updated in a while. It must have been before November 16. Today I saw that things were hopping there again. And then I saw it. “FlightGear 0.9.10 universal binary pre-release 2 [released] 2006-11-24″. The full realization of my stupidity gushed forth. I was only getting 7-15 fps because I was running it as PPC binary through Rosetta.

Eagerly I downloaded the .dmg and gave it a try. It didn’t open. A closer read of the webpage indicated I needed RubyCocoa. Uh oh, I tried to play with that once and installing it was a pain. Not so now, they have a no-nonsense installer now. Good work RubyCocoa team! The qtruby guys could learn a thing or two from you. I might have to explore RubyCocoa again in the future now that it’s übereasy to install.

Now the launcher fired up. It has thumbnails of the planes, very nice touch. I tried to run FlightGear and got an error appeared in my logs. There was an exception in Options.rb on line 104. I looked at the file (FlightGear.app/Contents/Resources/Options.rb) and I couldn’t tell what line 104 was supposed to be doing. It looked like it wouldn’t hurt to comment it out, and that’s just what I did. Now it works like a charm.

What is the difference between a universal binary and a PPC binary in emulation? About a 3x speedup in FlightGear fps, that’s what. I did a circuit from KSFO at night with all the rendering options in the View menu checked (except shadows) and an empty .fgfsrc. 21fps on average, often higher, only occasionally lower. I did a circuit from KLRU switching between day and night. 50fps or better. That’s more like it.

I have a few ideas for the launcher (aside from the bug I mentioned above). I have my own launcher in qtruby that reads your .fgfsrc and even saves back to your .fgfsrc on request (without losing your comments). There’s a few more default options I’d like to see. I should be able to merge in my work into his launcher without much difficulty, when I get a chance. (That’s the catch, as always.)

I was less than fair in my previous assessment of the MacBook’s ability to run FlightGear. It is capable of running it at passable speeds if you disable some things. I went through the output of fgfs -h -v and disabled everything that could be disabled (almost) and I get about 20fps when I’m not looking at the KSFO terminal or something equally busy. Even then it’s 14 or 15. That’s flyable. Using the 2D cockpit (or no cockpit and just the HUD) will buy you a couple of frames per second. But so will using a less-complex 3D cockpit, e.g. the Piper Cherokee Warrior II or the Northrop T-38. Flying during the day will buy you a lot (something about airport lights). One nice thing is that you get basically the same frame rate with the window maximized (or full-screen) as at 640×480. It’s not pixel-bound, in other words. Most of the checkboxes in View|Rendering Options make no noticeable difference, except shadows, and I don’t know about the lighting options since any nighttime flying with airport lights is too slow to bother.

So here’s the ~/.fgfsrc that gets me 23fps average in the air away from the airport in the Piper Cherokee Warrior II.

--disable-random-objects
#--enable-ai-models
--fog-fastest
#--disable-enhanced-lighting
#--disable-distance-attenuation
#--disable-specular-highlight
#--disable-anti-alias-hud
#--disable-hud-3d
#--disable-clouds3d
#--enable-fullscreen
--shading-flat
#--disable-skyblend
#--disable-textures
--aircraft=pa28-161

One of these days I’ll see which of the three remaining I can trim also, but it
looks good enough for now.