Blog

We Have Our First Patch

Austin just posted an announcement.  The short version: we have the first patch to X-Plane 10.  You can read more about how to get the patch here.  A few key points:

  • You don’t have to re-download the whole sim!  You can simply run an update, which will get only the changed files.  Less than 150 MB, I think.
  • If you can’t run X-Plane 10 because the app isn’t getting along with your graphics card, you can still update – just run the updater directly.
  • We have posted a new torrent – zipped, so it should be smaller, have correct permissions, and not drive µTorrent nutty with too many files.

Compatibility With Graphic Cards

I’ll try to post on-going status updates with regards to graphics card support; I’ve posted a chart on the wiki.  If you have gotten one of the cards for which the status is “unknown” to work, please post a comment.

The two cases that I believe we have fixed for the 10.02 patch are Intel HD integrated graphics and Radeon X1000 series GPUs – both were not functioning due to bugs in X-Plane (which were revealed by the particular capabilities of these cards).

I was surprised by how many reports of Intel HD graphics crashes we got but in hind sight it makes sense: everyone with a Core i3/i5/i7 chip has one of these GPUs, since it is built into the chip.  In some cases, users were running on the Intel GPU despite also having a real GPU, so even with the crash fix, those users will need to figure out how to change their default GPU.  (For a desktop this is usual a BIOS operation – for a laptop it’s usually black magic.)

I still have at least six different GPU crash cases that I am investigating, so there’s a lot of compatibility work to do.

The other major compatibility problem I am hearing about is just a slew of reports of weird stuff with NVidia GeForce cards.  Graphic artifacts, hangs, screen corruption, two copies of the app – you name it.  It’s going to take a while to figure out what’s going on.

Framerate and Performance

We put out X-Plane 10.02 to fix a few crash problems and cases of graphic corruption; there are only a few performance tweaks along for the ride.  The majority of performance work is still to come.  You may get a few fps back with AI planes, or if you have a Mac NVidia GPU.

Posted in Development, Hardware, News by | 42 Comments

Torrent Issues

A few notes about the torrent.

First: the torrent contains a single FranceVFR custom DSF that is not present in the regular demo install.  This file is due to a mistake made by me while building the torrent; the FranceVFR team sent me the file to test v10 compatibility and I stupidly used the same version of X-Plane to build the torrent.  My gravest apologies to the FranceVFR team for not being more careful with their IP.

Second: if you can’t execute the apps on OS X or Linux, it’s because the permissions are not set correctly.  I have no idea why that happened – the permissions are correct in the source files.  There are two ways to fix this:

  1. The easy way: delete the apps, then run the X-Plane 10 updater for Mac, Win, or Linux.  By deleting the apps first you’ll get new ones from the net with correct permissions.  Or
  2. The nerdymanly way: chmod u+x X-Plane.app/Contents/MacOS/X-Plane in the terminal from the X-Plane demo directory.

This will fix the app bouncing and then disappearing.

Third: for some reason the torrent won’t finish on some torrent clients.  I have no idea what that’s about, the solution to all three problems for the next patch is: I’ll build a new torrent and zip it into one big file.

Posted in News by | 21 Comments

A Few Settings Tricks to Try

For those who cannot wait to try to get X-Plane 10 to run fast, a few tips on how to ‘break down’ where a bottleneck might be:

  • Run with clouds vs. clear skies.  The clouds chew fill rate.  Are clouds the issue?
  • Turn down visibility – X-Plane 10 will run at 100 nm but some machines will die with this.  Does a low visibility help?
  • Turn off the AI planes.  Any better?  They take draw time when on screen and cores.
  • Turn down texture res if you haven’t already.  (Well, most people try that by default.)  Start with low settings and work your way up.
  • Try areas away from KSEA.  Compare down-town to rural, and different airports.
  • If you have an nvidia card before the 400 series, try running with –no_instancing from the command-line.  This can particularly help Mac users.

In most cases there is only one setting killing your framerate – find it, fix it, and things get a lot better…fix it and you’ll find those other settings you turned down can go up at least a bit.

The gotchas in v10 are definitely different from v9.  Shadows can kill your fps in a huge way – I’ll be spending a bunch of time tuning them to look better and kill fps less.  Turn water reflections down if you don’t need them – the “advanced” setting is frankly a bit pointless.  Turn off full screen anti-aliasing if you are going to run in HDR mode, then restart the sim.

Posted in Hardware by | 56 Comments

Rendering Settings and FPS: Don’t Panic

I am still trying to dig out my in-box this morning, but Chris tells me that there is a lot of concern over X-Plane 10’s framerate.  For now I can only offer one bit of advice:

Don’t panic.

I have no doubt that many users are seeing terrible fps with version 10.  But I think that we’re going to get this sorted out over the next few weeks and the end result will be really good.

How can I think that when so many users are seeing poor performance?  Here’s why…

  • With X-Plane 9, four years after its debut, you still can’t run X-Plane 9 at extreme objects on a modern computer.
  • With X-Plane 10, all of 1 day old, with very little performance ,i can run at extreme objects on my core i5 and get > 20 fps in the demo area.

In other words, the hardware usage of v9 was never properly “fit” to the capabilities of a modern desktop.  By comparison, version 10 is at least on the right curve, and we know how to tune for performance.

Please bear with me for a few days: the current state of chaos in our server download farm is a high priority right now, as are a few serious bugs.  So if you send me a list of your hardware specs, settings, and some numbers, I cannot help you.

When I do have time to look at performance (hopefully real soon) here’s how we will do it:

  • I will post some standard fps-test command lines that you and other users can try.
  • You can send me back the log.

One I have that data, controlled for all rendering settings, across a variety of hardware, then we’ll be able to understand performance and fix engine bugs and provide work-arounds.

X-Plane 10 is only fast if it hits the fast path through the driver every time it needs to; there are all sorts of little things that can go wrong that can kill fps that are not an indication that long-term the sim will suck.  We have worked through nasty performance issues before and we will again!  It took two months to kill off the very last driver problem in X-Plane 9.0 – I certainly hope it won’t take that long to get the vast majority of users running well in version 10.  But I do believe that fps problems we see now may be as much a case of driver vs. engine quirks than a fundamental performance gap.

Posted in Hardware by | 34 Comments

That Burning Smell

Happy Thanksgiving!  X-Plane 10 is now out the door, and over the next few weeks I’ll post on a number of topics.  But for tonight: that burning smell is our five download servers pushing 100 mbit each and not even coming close to meeting the demand for X-Plane 10 demos.

We are working on this now, and over the next few days we will get more servers into the pool.  But first we are going to analyze traffic and try to find the most efficient way to deploy our available bandwidth given such high demand.  Hopefully over the next few days we’ll be able to improve overall demo download times.

The demo is 2 GB and a lot of you have fast pipes, so it’s going to be slow going for a bit no matter how many servers we throw at the problem.  If you can run BitTorrent, you may want to give it a try, but we are definitely working to make a straight demo-download a viable option.

 

Posted in News by | 30 Comments

ATC: Description of a System Pt 1

I’ve always been into photography as just one of my many expensive hobbies. A very respected Photographer Jerry Ghionis always says “You don’t have to be the best, you just have to be better than last week.” I’ve tried to keep that in my head while working on the ATC system because like you, I too want it to be the best…and that’s the long-term goal, but I have to be honest, the ATC system in X-Plane v10.0 is not perfect. There, I said it! The ATC system is a tough thing to model not just because of its complexity but also because humans are inconsistent and unpredictable. Humans add a touch of randomness to every decision from the simplest thing such as phraseology to the most elaborate thing like vectors for an instrument approach.

What I can say however is that it’s a system that’s designed to get better. Until now, the ATC system has been very stagnant with little improvement or change in many versions. I’ve completely started from scratch and come up with a system that can be built off of so that it gets better and better. If you think you have a list of requested features, I’m willing to bet that my list is longer. Like the scenery system and many other systems in X-Plane, there’s ALWAYS something that can be done to make things better.

Another thing to consider that may not be obvious to a lot of people. The ATC system is really two pieces in one. Of course, there’s air traffic control to give you instructions but more importantly (I’d argue) is the AI traffic. Before, AI aircraft just flew around doing whatever they felt like…almost like zombies. Now however, ATC has control of them. That means they play nice, it means they follow you around to some extent so that the world is alive wherever you go. It may not seem like much but when you turn the AI traffic off, you’ll feel very alone. My point is, airports now FEEL like airports. Even if you decide never to use the ATC system directly, just having the hustle and bustle of a busy airport is a win. Before anyone asks, yes the system is currently limited to 20 AI aircraft. The aircraft are on their own threads so those of you with multi-core processors will certainly rejoice in seeing that things are using those other cores. In the future, we do plan on having alternate ways of getting the traffic count up higher for really busy airspace but I’m not willing to discuss that just yet.

So what can you expect from the INITIAL release? AI planes will be around you. They’ll be on the field departing and arriving with you. As you depart and fly around, they’ll transition to pass by you enroute. You’ll hear/see them on text and voice and even out the window. AI planes run REAL physics so you’ll see controls deflecting, flaps moving etc. As a human, you can file a flight plan, grab a clearance, get taxi instructions, get a takeoff clearance, you’ll transition to Departure or Center. They’ll issue step descents and vector you in to an ILS or visual approach at your destination.

We also have designed in a lot of customization in the traditional X-Plane fashion. You can customize the voice and text phraseology. You can (and should) come up with your own airport taxi layouts. Insert hold short points, tag the taxiways with the real names, create your own runway flows and of course customize controller airspace and frequencies.

A note on runway flow which i think is really neat….You specify which runways get used for different operations based on wind, ceiling, visibility, time of day, initial heading after departure and aircraft type. This lets you model how the real airport functions under various conditions not just for realism but also for efficiency (which is why the real world does it that way to begin with).

There are a lot of features still left to add but I hope you’ll understand that it’s a brand new system in its infancy. I hope you can see that our goal is to continuously add features and improve it incrementally…and also do this while offering users ways to customize the experience. What you see in v10.0 is NOT the end of ATC development. It’s just the very beginning.

Finally, please do NOT ask “Will we have feature X?” or similar variations. I do not want the blog to become a center for feature requests…especially on a system such as ATC that’s just been born.

I keeeeed!

Posted in Air Traffic Control by | 115 Comments

Mommy where do baby airplanes come from?

“Well little Johnny, when a KC-10 and a 747 love each other very much…”

On a more serious (kinda) note, this is a shot of what happens when ATC fails at spacing its aircraft properly. These two planes flew all the way down the ILS like this which is obviously a bug…but fun to have a chuckle about as well. If you look off into the distance, you can see some other aircraft, also on the ILS lined up against the golden sky…very dramatic!

(Notes: This is v9 scenery, v9 planes, a slow debug build…nothing special here)

Posted in Air Traffic Control, Blooper Reel by | 42 Comments

This is the Calm Before the Storm

I haven’t had much time to post, and it’s going to very quiet for another two to three weeks.  This is the calm before the storm.  Everyone on the team is somewhere past redline trying to get as much as we possibly can into the initial release.  We won’t get everything we want into 10.0 – we already knew that – we have too many ideas and there is way too much potential unlocked by some of the major changes to X-Plane.  But we’re still going to try to stuff the release as much as we absolutely can right up until the clock runs out.

So: please bear with us for a few weeks.  There is a ton to discuss, and once we get that DVD master burned, I’ll be in a position to answer more questions, describe some of the new features (which we are really excited about) and generally come out of hiding.

Back to code…BBIAB.

Posted in Development by | 21 Comments

We Spent That Efficiency (And Other Caveats)

I’ve seen a lot of fretting in blog comments and forums to the tune of “I’m afraid my computer won’t be able to handle X-Plane 10.”  And sometimes the response is “it will be more efficient than version 9.”  I want to take a second to address both points.

First: don’t panic.  Wait for version 10 to come out, then try it.  You might be pleasantly surprised.  If your computer is an absolute basket case on version 9 (or your graphics card is dropping below our minimum hardware requirements*) then version 10 won’t work for you, but if you can run 9, you may be able to run 10 acceptably.  It’ll be a question of whether you’re happy with the graphics quality or you want more.

Second: yes, X-Plane 10 is more efficient at a number of very specific rendering tasks.  (For example, we have a number of much faster OBJ paths, and improved memory use for draped meshes and forests.) But there are a few reasons why you might not see the win:

  1. In some cases, the efficiency only helps certain parts of the system.  If we make forests use less memory, and you turn forests off, you get no memory savings compared to version 9.  The performance work is specific to subsystems, not across-the-board.
  2. In some cases, we made the system more efficient and then promptly “spent” that efficiency by drawing more stuff.  For example, we can draw a lot more cloud vertices per frame, but the new weather system makes more cloud puffs.  So the system is more efficient but you need that efficiency to handle the more complex effects.
  3. A few of the new effects are always on. If something is expensive, I’ve tried to leave it out of the lowest settings, but there are some effects that don’t have an off switch.  For example, X-Plane 10 always runs with a linear lighting model – and at the lowest setting this still costs a few percent of your GPU.
  4. The rendering settings don’t match up between version 9 and 10.  “Tons” of objects doesn’t mean the same thing in versions 9 and 10.  The art assets aren’t even remotely comparable.  So if you send me a screenshot of your rendering settings in version 9 and 10 and ask why your framerate is different, I am going to politely direct you to what you actually see on the screen, which will be quite different.

This is all pretty normal for a major version.  I try not to raise the cost of minimum rendering during a version run so that everyone can update without buying new hardware.  So when a major version and hardware spec reset comes along, we have to normalize our configuration a bit.

Finally, I’ve said this before but: I am not going to answer any questions about “will my machine run well with X-Plane 10.”  X-Plane 10 isn’t done, I don’t have your machine, and what defines good performance has everything to do with what rendering settings you select.

(See also the thread on the org where a user put in a big GPU upgrade and felt like he got nothing because he couldn’t increase object count.  He could get better FSAA settings, but unlike some users, he just didn’t care.  Many other users won’t run with anything lesst han 4x.  The sim has too many options and user preferences are too varied to define “good”.)

* X-Plane 10 will require a graphics card that has programmable pixel shaders – if you are still nursing a fixed-function graphics card, you won’t be able to run version 10.

Posted in Hardware by | 52 Comments

What’s This Whole PCIe Thing About, Anyway?

I’ll try to summarize some of our hardware findings for X-Plane 10 over the next few posts.  But in my previous post I mentioned that the new MacBook Pros have only an 8x PCIe connection to the discrete GPU (that is, the nice GPU that isn’t built in to the CPU, the one you want to fly X-Plane with) and this got a bit of attention.

So it begs the question: what is this PCIe bus and why do we need to  care all of a sudden?

The PCIe bus is the connection between the CPU/main memory and your graphics card (with its memory and GPU).  It is the bottleneck through which all communications must flow – sometimes every frame, sometimes every now and then.

PCIe slots are named by the number of lanes (e.g. 16x means 16 lanes) – each lane has fixed capacity (which is doubled in PCIe 2.0).  So a graphics card in a 16x slot drink data from your computer at double the rate of one in an 8x slot – it’s an extra wide straw.

(Nerds: I realize this is about the worst description of the PCIe bus you will ever find.  Go read Wikipedia!)

What Do We Use the PCIe Bus For?

X-Plane needs the PCIe bus to:

  • Send the instructions to draw each frame to the GPU.
  • Transfer any textures, new OBJ meshes, and other data that will be held in VRAM.  The data is born on the CPU, goes over the PCIe bus once, and then lives in VRAM.
  • Send to the GPU anything that changes every frame to the GPU.  For example, smoke puffs and car headlights have to go over the PCIe bus every frame because they are constantly changing.
  • Send to the GPU mountains, forests and other non-repeating geometry.  This data gets sent every frame.

If the sum of all of the stuff on that list gets too big, your framerate drops as the CPU and GPU both wait data to make it over the bus.  In other words, the bus can at times be the bottleneck in terms of framerate.

If you set your rendering settings near the maximum that your computer can handle and get the occaisional stutter, that may be X-Plane running out of PCIe bus bandwidth.  As you fly to a region with new textures that haven’t been used before, the OpenGL driver will transfer our textures over the PCIe bus from system RAM to VRAM.  If the PCIe bus is already nearly maxed out, the extra traffic of those textures is going to temporarily hurt framerate – sometimes in the form of a stutter or pause.

Are You Sure You Know What You’re Doing?

At this point those of you who know some things about 3-d graphics are shouting at your monitors: why are you guys transferring the mountains and forests over the PCIe bus every frame?  Why not just put them in VRAM, since they don’t change?

That’s a good question and if you have a better solution than the one we use, I’d love to hear it.

The problem is this: OpenGL doesn’t give us a good way to prioritize which meshes (VBOs) stay in VRAM and which ones are purged out when we run out of VRAM.  If we put every mesh in the sim into VRAM, framerate gets better (because we aren’t using the PCIe bus) right up until we run out of VRAM.  At that point the OpenGL driver freaks out and starts throwing out textures to make room for meshes, and then the textures have to be sent back over the PCIe bus, and we end up in a world of hurt.  We end up in a state of texture thrash as we have too much “stuff” for VRAM and framerate falls off of a cliff.

The real problem is this: X-Plane has no idea how much VRAM is available for its own use.  Sure the card might have 256 MB, but how much is being used by the OS window manager for those translucent window effects, or by other applications?  We can’t even add up how much VRAM we use with ultimate precision because we don’t know the granularity of allocation on the video card (there’s real overhead for VBOs being rounded up to the VM page size, for example) or whether side buffers like a hierarchial Z buffer have been allocated.

X-Plane works around this with a simple rule: all OBJs go to VRAM, because their geometry is likely to be repeated, and non-repeating geometry, like forests and mountains, stay in system RAM and go over the bus.

This heuristic actually works pretty well in X-Plane 9 – we have enough bandwidth to transfer all of that “stuff” once per frame, and we tend not to run out of VRAM and thrash.

Why Does X-Plane 10 Want more PCIe Bus Bandwidth?

X-Plane 10 is hungrier for bus bandwidth for three reasons:

  1. The OBJ engine’s performance has been improved a lot.  In the past, we’d run out of CPU capacity (to draw OBJs) long before we ran out of bus bandwidth.  This isn’t always the case with X-Plane 10.  The graphics are always held back by their weakest link.  If you have a strong GPU (and low effects settings) and the OBJ engine is efficent, the PCIe bus is the weakest link.
  2. The art assets are more detailed and thus contain more vertices.
  3. Shadows.

When shadowing is on we have to draw the entire world multiple times, once to build shadow maps and once to draw the real world.  So shadowing can double (or even triple or worse) our bus bandwidth usage.  We didn’t have that kind of free capacity on the bus in the first place.

We’re still working on the engine, art assets, and performance, so my hope is that we’ll find ways to cut down bus use (especially with shadows).  And there has to be one slowest part of the system – as of this writing, the PCIe bus is often it.

Posted in Development, Hardware by | 25 Comments