Category: Computing

And while I’m sitting here waiting for my source to build, I’m going to rant a bit about the vaunted X-Plane flight simulator. Last fall I replaced my ailing Windows machine with a nice shiny new iMac 20″ G5. (About a month before the announcement of the Intel machines… Grr.)

I was a little worried about not being able to run Flight Simulator any more, but from the hype on the web, X-Plane was more than enough to keep me happy. Little did I know.

To put it simply, X-Plane sucks. It’s a matter of production values. First, let me say that the new global terrain graphics are perfectly adequate. Graphics are not the issue.

First of all, the simulation engine changes with practially every single minor revision of the software. That means that planes designed for one version of the software fly wildly differently on others. And since updates are released about every six weeks, this is a major problems for one’s enjoyment of the product.

Second, the planes are crap. If the have a 2D cockpit, it’s only good for one resolution, and doesn’t scale to others. So I have to downgrade my screen to 1024×768 to fly, either sssstttrrreeetttccchhhiiinnnggg to fit my wide-screen monitor, or leaving black bars on each side. If I’m in 3D cockpit mode, most of the planes just have the 2D cockpit hanging in empty space in front of you. Any change in viewpoint from the default results in a jarring cognitive dissonance.

Third, the interface is crap. You cannot get a joystick coolie hat to move your view in both 2D and 3D cockpit modes at the same time.

Fourth, the avionics are crap, as are plane builders’ instrument choices. If you’re going to simulate anything more complex than the S-TEC, include a FLCH function. Trying to level some wildly overpowered fantasy jet before I can hit altitude hold is an exercise in futility. And the autopilot . . . what can I say. Don’t eat a large meal before engaging it, is all I can say. X-Plane is singularly responsible for introducing me to the concept of AIO: autopilot-induced oscillation. In all dimensions. And don’t even think about mentioning the FMC. If it bothers to notice a turn at a waypoint, it takes its time telling the autopilot.

Fifth, the AI air traffic control is crap. It takes no notice of airspeed when commanding descent, so many’s the time I’ve been instructed to call the tower on ILS intercept — and found I was at angels 10, one mile from the runway. This is probably the reason it nags you every 30 seconds whenever your rate of descent slips above -6000fpm.

Ordinarily I’m all in favor of the little guy — I’m writing a spaceflight simulator I hope to release someday — but in this case, production values win out. As soon as I can I’m buying a windows machine to run FS X on. X-Plane is pretty much the most disappointing $60 I’ve ever spent on software.

So I’m getting into the swing of things here at work. It’s a pretty nice place to work — the people are relaxed and friendly, and charmingly cynical about their absentee managment. The code is innovative and of good quality.

But the build system. Oy.

Is it merely a pipe dream of mine to eventually find a place where setting up one’s build environment consists of one checkout, and the head branch — if the source control system is capable of branching at all — is always in a buildable state? These things can be made company policy, you know!

But no, the build master is a secretive gnome who’s never around. Checking out the source requires mapping a double dozen directories to random places in your working copy. There is a common include directory that has CPP files in it that are compiled multiple times in different projects. There are binaries in the source code repository. The Visual Studio project settings are massively inconsistent between projects and configurations. There exist multiple massive contradictory documents on the process, but building the system requires multiple tweaks.

I’ve done this twice now, the first time last week with the crap machine I had at first, and now the last two days on my good machine. It takes two days on a fast machine to set up and build the initial development environment. Oh well, it means I can read more blogs…

Here’s some policies for a sane and problem-free build system:

• Use a source control system that supports branching. Perforce, Vault, Subversion, etc. NOT VSS. (Caveat: I haven’t tried the new VSS yet, but the old one is clearly from the hot place.)
• The directory structure of the repository should mirror the structure of the working copy. You’d think this would be a no-brainer. The people who “designed” VSS’s “set working directory” functionality must have been smoking something powerful.
• Checkins to the head branch must always build. Breaking the head build must be an officially reprimandable offense. This can be enforced in software, with a decent source control system.
• Keep Visual Studio project configuration standardized across configurations. This means you have to learn about $(OutDir), $(TargetFileName) and friends. NEVER hard-code a directory in a project configuration except the initial output directory setting.
• Keep VS project configuration standardized across projects. If all the binaries are going in one directory, point $(OutDir) at that directory in all projects. Don’t have batch files copying things around in some projects.
• Binaries never go in the repository, unless they’re third-party software needed to build.
• Make sure the entire thing can be versioned, configured, tagged, built and packaged with one click. Now schedule it for every night, and burn the resulting source and package to a CD. This way you’ll have a consistent record of development.

For more excellent advice, see Mike Gunderloy’s excellent Coder To Developer. If there’s one software book you buy this year, make this the one.