Blog

X-Plane 850 framerate and efficiency

Austin and Randy and the gang are out at Oshkosh right now – with Austin out of town there won’t be a new beta for at least five days. In the meantime I’ve had some time to look at X-Plane 850’s performance and tune the code a bit. (The next beta should be faster than beta 4.) I’ll cover performance in a few blog posts because there are a lot of issues.

For today I’ll stick to my usual rant: the difference between frame rate and sim efficiency. Simply put:

frame rate = (sim effiency * hardware power) / (visibility * scenery complexity)

Basically the sim gets faster with a bigger computer or more efficient code, and it gets slower as visibility goes up or you load more art into it. (By art I mean more complex 3-d models, bigger textures, more complex DSF meshes, more roads, or any other content that looks better but makes the sim do more work.)

Sim efficiency is only one of several factors in the equation, but, as a programmer, it is the one I care about most. For every release of X-Plane, I try to measure and confirm that the sim can process scenery at least as efficiently as it used to. If our efficiency goes down, your framerate goes down with nothing in return.

So in looking at the puzzle of low framerate in X-Plane 850, there are two questions we have to answer:

  • Is the sim less efficient than 840? (The answer, BTW, is yes, 850 beta 4 is less efficient, and I am working to fix that now!)
  • Does the set of artwork we’ve included in X-Plane 850 weigh down the sim more than the artwork in 840 when the same rendering settings are used? (The answer is: apparently not or at least not by any significant amount, but more research is needed.)

The point I’d like to make here is: nothing is free. We want to be as efficient or better than 840 (and when we’re not, we work to fix it!) We want to make sure that if you don’t use the new features, the old features don’t cost any more than they used to. But we do not
try to keep the framerate the same if you turn on new things that you didn’t have before!

We cannot give you something from nothing. If the sim ran at 30 fps with no cars before, it’s probably not going to run at 30 fps with cars – cars take time to draw. Some examples of what’s new in 850:

  • 3-d structures on all of the runway lights (this can be shut off by disabling textured lights).
  • Cars on the roads (controlled in rendering settings).
  • Birds flying around (controlled in rendering settings).

We’ve also redone the models for the ships and hot-air balloons. The new ones are more complex than the old ones and probably slow the sim down a little. Why didn’t we provide a fallback to use the old fast artwork? Well, at some point if we try to provide everyone with every rendering setting we’re asked for, the rendering settings dialog box will look like the cockpit of a 747-100. So in some cases we try to set something up that is reasonably fast and useful but not too complex, so ordinary users can understand the settings. In a later post I’ll cover some of the tuning tricks you can use to maximize performance.

Coming up next: the relationship between VRAM usage and framerate.

Comments Off on X-Plane 850 framerate and efficiency

Cars on the wrong side of the road

In the next few betas the cars will drive on the left side of the road for the UK and other countries that do that kind of thing. There are actually two sim changes to make this happen:

  • The road.net format allows us to specify where on theh road the cars drive, as a ratio from 0 to 1 (0 = all the way to the left, 1 = all the way to the right). So in the US, all car positions are mor than 0.5 but in the UK less than 0.5.
  • The library system now allows you to specify that a given file only be used in certain DSFs by painting a bitmap. So Sergio made a black and white PNG file with the right-side countries in black and left-side countries in white. I made a special road.net with the lanes on the left, and the PNG file controls which road.net gets used (the normal one or special left-side one).

I will try to post the spec for using PNG files to control library export in the next few days. This is a very powerful feature because it lets you paint the regions over which objects may be used. This technique will work for roads, objects, facades, or any other type of file used by X-Plane.

2 Comments

Random Thoughts on 850 beta 1

X-Plane 850 is now beta – see item 7 of Klingon Software Development. A few random thoughts:

We aim to make each new patch of X-Plane “performance positive”, meaning for the same settings as the previous version, the new version will run faster. X-Plane 850 is definitely not performance positive right now, but this is mainly because it is an early beta. Expect lower framerates until we have time to do some tuning work and analysis.

X-Plane 850 supports a new apt.dat revision with curved taxiways, lines, etc. However you will not see this in the betas. The reason: the sim supports the data, but we have not yet shipped any new layouts using these features. Until custom scenery authors and layout creators adopt the new features you won’t see them in the sim, even though the capability is there. Because we have not yet released editing tools for these new features, it’ll be a bit before people can take advantage of them. (You can make curved taxiways now by reading Robin’s spec and then using a text editor, but this is a very slow and painful way to make a layout. This is how I have to make taxiways to test the code right now.)

Finally perhaps most important: Austin and I do not have time to follow all of the various on-line forums and communities, so if you post a bug to a forum but don’t file a bug report with us, the bug probably won’t get fixed! Please use our bug report web page to file bugs with the new beta.

(The bug report web page is for bug reports only. In particular, if you bought X-Plane and are having trouble with it, please email info at x-plane dot com to receive tech support. Filing bugs will probably not get you timely tech support, but emailing our tech support people will.)

Comments Off on Random Thoughts on 850 beta 1

Transparent Runways

X-Plane 8.50 does all sorts of new things – the picture on the left illustrates “transparent” runways. A transparent runway draws no pavement and does not affect the physics model. But it does have all of the runway lights, signs, and shoulders (if desired).

The purpose of transparent runways is to allow custom scenery to use X-Plane’s built-in approach and runway lights while providing your own runway, perhaps via an object with a hard surface.

Technically you could build your own approach and runway lights by hand-placing light objects (from the 850 light library package) onto your runway, but using a transparent runway is a lot easier and probably more reliable in the long-term.

3 Comments

Tools – it’ll get worse before it gets better

Here are some musings on the scenery tool situation…first the bad news:

I think 850 will ship with no WorldMaker at all. WorldMaker 8 cannot edit terrain, airport editing is being moved to a separate program, and navaids and fixes are now edited inside X-Plane.

The new scenery tool will probably not be ready by 850 beta 1. I hope to have the first beta of the scenery tool available during the X-Plane 850 beta process – but the scenery tool beta may go on longer.

I am considering 850 airport editing to be higher priority than overlay editing – Jonathan Harris already has a cross-platform overlay editor, but there are no 850 apt.dat editors, so I may release the scenery tool with airports first, then put overlays in later, to get people started with the new airport technology.

Finally the new editor will not be able to save older airport layouts. It will be able to read them, but they will be converted and saved in the new format. If you need to edit old layouts I suggest you use TaxiDraw.

So is there any good news? Well, the main work on the apt.dat format is done, so we’ll have a ton of new features for modeling detailed airports. Bezier curved pavement, taxilines, signs
specified by their text, and a whole new lighting system.

Also once 850 ships, scenery tools will be my number one top priority, so I think that while the first few betas of the new scenery tool will be painful and awkward (as we get the basic UI and usability features in place while simultaneously trying to fix X-Plane bugs) I think that we’ll pick up a lot of momentum once 850 ships.

Also one note on platforms: the new scenery tool will ship for Mac first, then Windows. I don’t have specific plans for Linux, but how soon it happens dependes partly on who I can enlist to help with a port (I don’t have a Linux box) and partly on whether it works under WINE (I suspect it may). The whole project will be open-source too so anyone who wants to try to get it working on system X will be able to. With the first beta I should have a “real” source distro, as much as is possible given the development tools I’m using.

Comments Off on Tools – it’ll get worse before it gets better

It’s supposed to just work!

X-Plane 8.50 will introduce a new version of the apt.dat file, but it is also designed to support old apt.dat files without any changes. So if you download the 850 beta (not out yet, but soon!) and an apt.dat file that used to work stops working, that’s a bug!

If you hit this case, please do not change your apt.dat file to work around the problem – instead please file a bug. A link to our bug reporter can be found on the bottom of this page.

Also OS X 10.4.7 is out and we’ve received some reports of crashes. So far these appear to be related to custom scenery packages using ENV. If you remove custom scenery and the crash goes away, then please try to identify which scenery package in particular crashes (ideally which ENV file), and then file a bug with that specific package. If we can get a specific package that causes the problem, we’ll be able to fix this a lot quicker.

Comments Off on It’s supposed to just work!

Taxi Signs

Starting with X-Plane 850 (not quite beta yet), the apt.dat file will allow you to build taxiway signs into airport layouts. We’re using a simplified version of the sign-specification language from FlightGear (which shares apt.dat data) – you can read the on-going spec/discussion here.

The syntax isn’t final, but here’s a rough idea of what it will look like:

20 42.363178 -71.012238 110.0 {@R}22R-4L{@@}4L-22R
and here’s an example sign (not the same as the apt.dat example listed above):

The basic idea is: a sign has a latitude and logitude location and a heading (in this case 110, so the front of the sign is visible when parked to the east). The text of the sign is plain text – special characters are put in braces {} and special formatting starts with a @ character. @R turns the sign red, @Y yellow, etc. and @@ changes to the back side of the sign. Arrows are specified with a ^ followed by the direction, so a left-downward arrow is ^ld.

1 Comment

SPAM – the cure is worse than the disease

Well, the disease is pretty bad too. I spend more time than I’d like to admit to Austin deleting ads for blue pills, credit cards, and dirty websites on the XSquawkBox forums, this bog, my in-box, etc.

Unfortunately one of the side effects of all the spam floating around out there is that anti-spam software is starting to defeat normal communications.

Email is the primary means of communications within Laminar Research and we periodically lose valuable development time when one of us ends up black-listed on an anti-spam list.

Recently I’ve also been hitting cases where I either can’t return an email from a user at all (they can email me but I get spam-filtered when I reply) or the reply requires me to authenticate myself in some way (which takes away from the total volume of email I can answer and makes everyone’s responses slower).

So if you have emailed me about scenery and heard nothing it could be my horribly clogged in-box, which is months behind, but it could also be that I emailed you but was a casualty of the war on spam.

Comments Off on SPAM – the cure is worse than the disease

The little things…

It’s the little things that often take the longest to program, or at least make developing a feature take longer than expected. But I think flight simulation has reached the point where the details are what matters.

Trivial example: if we have a runway that’s shorter than 9000 feet and about an even multiple of 1000 feet then the distance-remaining signs (every 1000 feet) from the two directions may be too close to each other or even overlap. X-Plane 850 will detect this case and generate a single two-sided distance-remaining sign (like real life), so that the signs don’t obscure each other.

If the runway length is such that merging the signs would create too much error in their measurement, or we only have a sign in one direction, there is no merge.

The 850 airport code is full of tiny details like this.

12 Comments

Cleaning up the house

In Austin’s recent post to the news list he mentioned that we’d cleaned up a lot of code internally, making X-Plane tighter, leaner and meaner. But is this really a feature, something that you would care about as a user? I can think of at least 3 ways it directly affects the sim.

One difference between X-Plane and most other software is that you can email the authors and ask for a new feature and possibly see it within a few months. But when we evaluate feature requests, time to develop the feature is a big consideration. Having a cleaner code base means we can put new features in faster, which means everyone is a little more likely to get something new. (Of course, we can’t do every feature that is requested…this only improves the odds a little.)

Similarly, X-Plane is a subscription – so the amount of improvement you see across a version of X-Plane is directly affected by our ability to put new stuff in quickly. I’ve worked at companies with a range of policies toward code clean-up, and I’ve found that Austin’s policy of “constantly keep your house in order” (with major code cleanup on a monthly, not yearly basis) results in us being able to get a lot of cool things done without being held back.

Finally one direct result of code cleanup is often performance. For example, under the old code we really had two rendering engines. One handled DSF and ENV scenery, and the other handled airports, superimposed on top of them. Each one knew how to draw a bunch of triangles. Each one knew how to decide whether triangles needed to be drawn. Each one knew how to check whether the plane was on top of some part of the scenery (e.g. a runway or the ground).

This was bad for two reasons: first, it meant we spent twice as long working on anything – once for airports, once for scenery, and second, the two engines were not equal. It turns out the DSF/ENV engine, which is newer and has had a lot more time spent on it can out-perform the old airport rendering engine. This was an issue for 840 but is an even bigger issue for 850, where we want to make airports much more realistic.

By merging thet two and using only our better engine for both, we not only clean up our code, but airports render faster immediately. I do not have final stats on this, but the speed improvement is variable – anywhere from as little as 10% faster to as much as 50% faster depending on the view angle, airport chosen, visibility, etc. So even if you end up turning off all of the new 850 visual features and go for speed, 850 should still be an improvement.

Comments Off on Cleaning up the house