When it turns out that a bug that we thought was in an OpenGL driver is actually in X-Plane, I try to make a point of blogging it publicly; it’s really, really easy for app developers to blame bugs and weird behavior on the driver writers, who in turn aren’t in a position to respond. The driver writers bust their nuts to develop drivers quickly for the latest hardware that are simultaneously really fast and don’t crash. That is not an easy task, and it’s not fair for us app developers to blame them for our own bugs.
So with that in mind, what did I screw up this time? This is a bug in the framerate test that caused me to mis-diagnose performance of hardware instancing on NVidia drivers on OS X. Thanks to Rob-ART Morgan of Barefeats for catching this – Rob-ART uses the X-Plane framerate test as one of his standard tests of new Macs.
Here’s the TL;DR version: hardware instancing is actually a win on modern NVidia cards on OS X (GeForce 4nn and newer); I will update X-Plane to use hardware instancing on this hardware in our next patch. What follows are the gory (and perhaps tediously boring) details.
What Is Hardware Instancing
Hardware instancing is the ability to tell the graphics card to draw a lot of copies of one object with a single instruction. (We are asking the GPU to draw many “instances” of one object.) Hardware instancing lets X-Plane draw more objects with lower CPU use. X-Plane’s rendering engine will use hardware instancing for simple scenery objects* when available; this is what makes possible the huge amounts of buildings, houses, street signs, and other 3-d detail in X-Plane 10. X-Plane has supported hardware instancing since version 10.0.
The Bug
The bug is pretty subtle: when we run the framerate test, we do not set the world level of detail explicitly; instead it gets set by X-Plane’s code to set up default rendering settings for a new machine. This “default code” looks at the machine’s hardware capabilities to pick settings.
The problem is: when you disable hardware instancing (via the command line, explicit code in X-Plane, or by using really old hardware) X-Plane puts your hardware into a lower “bucket” and picks lower world level of detail settings.
Thus when you disable hardware instancing, the framerate test is running on lower settings, and produces higher framerate numbers! This makes it look like turning off instancing is actually an improvement in fps, when actually it’s just doing better at an easier test. On my RetinaBook Pro (650M GPU) I get just over 20 fps with instancing disabled vs 17.5 fps with instancing enabled. But the 20 fps is due to the lower world LOD setting that X-Plane picks. If I correctly set the world LOD to “very high” and disable instancing, I get 16.75 fps. Instancing was actually a win after all.
Was Instancing Always a Win?
No. The origin of this mess was the GeForce 8800, where instancing was being emulated by Apple’s OpenGL layer. If instancing is going to be software emulated, we might as well not use it; our own work-around when instancing is not available is as fast as Apple’s emulation and has the option to cull off-screen objects, making it even faster. So I wrote some code to detect a GeForce 8800-type GPU and ignore Apple’s OpenGL instancing emulation. Hence the message “Disabling instancing for DX10 NV hw – it is software emulated.”
I believe the limitations of the 8800 are shared with the subsequent 9nnn cards, the 1nn, 2nn and 3nn, ending in the 330M on OS X.
The Fermi cards and later (4nn and later) are fundamentally different and can hardware instance at full power. At the time they first became available (as after-market cards for the Mac Pro) it appeared that there was a significant penalty for instancing with the Fermi cards as well. Part of this was no doubt due to the framerate test bug, but part may also have been a real driver issue. I went back and tried to re-analyze this case (and I revisited my original bug report to Apple), but X-Plane itself has also changed quite a bit since then, so it’s hard to tell how much of what I saw was a real driver problem and how much was the fps test.
Since the 480 first became available on the Mac, NVidia has made significant improvements to their OS X drivers; one thing is clear: as of OS X 10.9.5 instancing is a win and any penalty is an artifact of the fps test.
What About Yosemite?
I don’t know what the effect of instancing is on Yosemite; I wanted to re-examine this bug before I updated my laptop to Yosemite. That will be my next step and will give me a chance to look at a lot of the weird Yosemite behavior users are reporting.
What Do I Need To Do?
You do not need to make any changes on your own machine. If you have an NVidia Mac, you’ll get a small (e.g. < 5%) improvement in fps in the next minor patch when we re-enable instancing.
* In order to draw an object with hardware instancing, it needs to avoid a bunch of object features: no animation, no attributes, etc. Basically the object has to be simple enough to send to the GPU in a single instruction. Our artists specifically worked to make sure that most of the autogen objects were instancing-friendly.
When I was very young, it was hard to watch my younger brother get presents on his birthday. I was jealous! Why should he get all of the attention? I was here first!
When I was just a little bit older, I realized that my brother’s birthday was actually a pretty good day for me too. You see, my brother and I had one big pile of toys, so whatever my brother received as a gift would be available to me too; all I had to do was be patient and not snatch his toys for a few days.
The new announcement for X-Plane 10 Mobile is clearly trying to whip up a little bit of sibling rivalry: “X-Plane 10 Mobile will make our desktop users jealous.” Besides being a chance to plug X-Plane 10 Global to mobile users, it is also a reference to the inevitable emails we did get (for X-Plane 9 vs X-Plane 9 Mobile) and will get from desktop users who are jealous of the development resources we spend on the mobile product.
Here are a few notes on X-Plane desktop and mobile and the relationship of the two products.
First, X-Plane 9 Mobile funded the development of X-Plane 10 Global. Had we not shipped X-Plane 9 Mobile, there would not be an X-Plane 10 Global, and I probably would not still be working at Laminar Research. So even if you ignore leverage and synergies between the code and you consider mobile products to be a distraction from the true purpose of X-Plane (desktop flight simulation), you can’t ignore that mobile is part of our business, perhaps a part that should not be discarded.
Second, we have been moving to a “two fronts” strategy where we can actively develop both products at the same time, and we have hired more developers so that we can do so. X-Plane 9 waited while X-Plane 9 Mobile was developed, and then the mobile product was more or less frozen for years while we worked on X-Plane 10 desktop.
The level of ping-pong hasn’t been as bad for X-Plane 10 mobile. We shipped 64-bit support, deployed the airport gateway, ported to Steam and shipped a brand new GPS while developing X-Plane 10 Mobile.* This has not been easy, but I think it indicates that we’re making progress towards “two fronts”. Both desktop and mobile suffer if they have to sit in the penalty box for years on end while the other is developed.
Finally, mobile devices are now powerful enough that we can share code and art assets between the two code bases. A few examples:
- Our minimum OpenGL requirements for the mobile product is OpenGL ES 2.0; our minimum desktop OpenGL version is OpenGL 2.0. And the capabilities required by both (render-to-texture via VBOs, vertex and fragment shaders) really are as similar as they sound.
- I have an iPhone 6 and a 2008 8-core Mac Pro. I ran the particle system performance test code on both and they run at almost the same speed. Obviously the Mac Pro is 6 years old and the iPhone 6 is a top-end phone. But there is no gap. This means that an older but supported desktop device will have similar characteristics to the top end of mobile devices. It’s just one big spectrum of computers now.
A lot of code was moved from desktop to mobile for X-Plane 10 mobile. But code was also developed for X-Plane 10 mobile with the intention of moving it back to the desktop version of X-Plane.
My take-away point: if you use our desktop product, you don’t need to actually be jealous of new toys in X-Plane 10 Mobile. Those toys are meant to be your toys too.
* One thing to note about this list: our ability to do more than one thing at once is mostly limited by who will do the work. Different developers and artists in the company have different skill sets; our developers are not interchangeable robots. Well, one of our developers is a robot, but I’m not going to name names.
In X-Plane 10, we started listing the plugin that crashed in Log.txt when a crash happens. This post is for plugin authors and provides one or two tricks to determine more information.
How Do We Know If a Plugin Crashed?
The mechanism for determining whether X-Plane or a plugin crashed is very simple: every time X-Plane dispatches to plugin code, we make a note that we are jumping into plugin land; when we jump back we clear the note. This way when we get a crash, if the crash is in plugin-land, rather than collect an automatic crash report (which we won’t be able to interpret) we let the OS crash handling go through.
This mechanism is not perfect. For example, when the sim reads an animation from a plugin, it does not mark the dataref read as plugin land, so a crashing dataref handler in a plugin will appear as an X-Plane crash.
How Do We Know Which Plugin Crashed?
The log from a plugin crash will say something like “X-Plane crashed because of a plugin: XSquawkBox.” (This is of course hypothetical; XSquawkBox would never crash. 😉 How does X-Plane know who crashed?
The answer is: it asks the X-Plane Plugin Manager (the XPLM). The XPLM tracks which plugin is executing at any given time; every time a plugin callback is dispatched, the XPLM notes which plugin owns the callback and marks that plugin as current. (This is also how the XPLM knows who owns resources; the plugin that is current when a resource is allocated owns the resource).
Note that if your plugin calls into X-Plane and X-Plane crashes, you still get blamed. For example, if you call us to draw an object (with XPLMDrawObject) but you pass us a bogus object handle, the sim will probably crash and you’ll take the wrap. This is probably the most useful case from a debugging standpoint; if your plugin calls our API and it crashes, we’re not going to look at it without some info about what your plugin was doing. You (the plugin author) get the crash report and can thus know in context how the call was happening.
(If these crashes were reported to Laminar Research, we’d have no idea what was happening in the plugin because we have no plugin symbols.)
Note that dataref reads are tracked by plugin, so if, in your flight loop callback, you call XPLMGetDataRef on a dataref provided by another plugin, and that plugin’s read handler crashes, they get logged, not you.
Who Is XPLANE_PLUGIN_XPLANE
X-Plane is actually registered as a plugin, because it provides datarefs. Therefore if you can crash in callback code registered by X-Plane (that was called from a major callback from a plugin, like a flight loop callback), we’ll log that we crashed due to a plugin, and that X-Plane is the plugin!
An example to illustrate this: your plugin registers a flight loop callback. From your flight loop callback you call XPLMGetDatavf to read an array dataref. The array dataref is owned by X-Plane but you pass an illegal pointer to XPLMGetDatavf, such that saving the values crashes.
X-Plane (the app) will crash inside X-Plane’s dataref handler (because writing to illegal memory will cause a crash). Because we’re in your flight loop callback, a plugin is going to get blamed, and because X-Plane’s “plugin” code (the dataref accessor functions ) were running, XPLANE_PLUGIN_XPLANE gets blamed.
There are only two bits of code that I can think of off hand where this can happen:
- Reading X-Plane built-in datarefs.
- Using the built-in 64-bit Lua allocator by sending plugin messages to X-Plane.
If you can consistently reproduce a crash blamed on XPLANE_PLUGIN_XPLANE, please let me know; it either means we have a bug in our datarefs, or your code is doing something illegal (that we should probably trap with error detection if it’s affordable). Note that we can’t catch the bogus-memory-for-array-dataref case without killing performance, so that’s going to remain a crash.
Crashing In a Worker Thread
Plugins do not have officially registered worker threads in X-Plane 10; therefore if a worker thread crashes, we don’t know if it is ours or yours, and we cannot issue approrprate blame. Currently X-Plane assumes that all worker thread crashes are sim crashes and auto-reports them.
If you do have a plugin that uses a worker thread and you think it might be crashing, you’d have to run from the command line with –no_crash_reporter to capture native OS crash information.
We (Laminar Research) cannot contact you to notify you of worker thread crashes caught by our crash reporter. Besides not having contact info for all plugins, the crash reports can’t trace the stack properly to determine who crashed, because we don’t have symbols.
Finding the Plugin At Fault in an Apple Crash Report
If our crash reporter catches a crash, we log the plugin at fault, and we make sure the complete Log.txt is written to disk. Similarly, if you log something with XPMDebugString, the log is written to disk immediately.
However, sometimes a crash will happen an we won’t catch it. Causes include a worker thread crashing, running on Yosemite (where, as of this writing, automatic crash detection is inoperative), etc. If you are on OS X the user will get a crash report, and it can actually be pretty useful.
The crash report does have one weakness: all of the plugins are named mac.xpl. How do you know who crashed?
It turns out each plugin’s binary gets a unique ID (UUID) which will be logged in the crash report along with its address range. You can calculate your own plugin’s UUID with
dwarfdump --uuid mac.xpl
The output will look like this;
bash-3.2$ cd DataRefEditor/
bash-3.2$ dwarfdump --uuid mac.xpl
UUID: 0C9A8216-95CB-2F45-D8B6-51B6168AC05D (i386) mac.xpl
UUID: 5A0D5A18-992D-FD89-3CF1-6299CBC8F03C (x86_64) mac.xpl
UUID: 66A96F33-3FFC-A36B-660C-533F006B590F (ppc7400) mac.xpl
This is the UUID for DataRefEditor. Note that DataRefEditor runs on three platforms (PowerPC, 32-bit Intel, and 64-bit Intel – you can actually run PluginAdmin in X-Plane 8, 9, and 10) and therefore it has 3 UUIDs, one for each architecture.
So if you see a mac.xpl loaded in an Apple Crash Report whose address range covers the crash and has your UUID, then you know you are the one who crashed.
(If I had known that so many crash report tools would delete the path to a crashing DLL, I would have considered a different naming convention for fat plugins.)
Since X-Plane 10.30 shipped, we have received a lot of feedback about the stability of X-Plane 10.30 – or rather, the lack thereof. We are getting more bug reports that the sim crashes, more tech support requests, and more discussion of crashing in the forums.
We don’t have a good way to characterize with hard data how much less stable 10.30 may be – unfortunately even the crash reports we gather don’t give us a statistically clear picture.* But with this much user reporting, stability is our first line of inquiry. 10.31 will come out shortly (and will fix a few issues) and we’ll keep investigating problems and pushing small patches (to fix stability issues without introducing new ones) until we’re back on solid ground. The rest of this post discusses some of what I’ve seen so far looking into stability issues.
How To Use the Automatic Crash Reporter
Since X-Plane 10.10, we’ve had the ability to send crash reports** directly to Laminar Research. Here are a few suggestions:
- If you need help, contact tech support! This is the most important thing. We do not read every single crash report! Instead we use statistical queries to locate and identify common crashes. If you crash and write in the comment field “please help me”, your cry for help will probably be lost.
- Please do report every time X-Plane crashes, even if the crash fields are blank. The reporter can handle huge quantities of crashes, and we’re trying to gather a statistical picture of crashes. If you get a crash every day, we want to know that it wasn’t a one-time thing.
- If you hit a reproducible crash (e.g. every time you follow a simple set of steps the sim crashes with a crash-auto-report dialog box), please file a bug and include the crash report (from Output/crash_reports). Reproducible does not mean “fly the sim and it crashes”. It means “start the sim with no prefs, open the C172, flip the avionics switch 3 times and the sim crashes” – specific steps with a known crash outcome every time.
Reproduction steps are gold to us – sometimes we’ll see a crash and the proximate cause is “hrm – the sim crashed drawing an OBJ”. Sadly this doesn’t tell us much about how to reproduce the crash – and clearly the sim does not crash every time you draw an OBJ; it wouldn’t start up.
The Problem with OpenGL Drivers and 64-Bit
Our crash reporter can only trace the origins of a crash through X-Plane code.*** Unfortunately, of the top 5 Windows 64-bit crashes in 10.30r2 (and this represents most of the crashing going on), 87% of the crashes originated in an OpenGL driver from AMD, NVidia or Intel. (This does not mean the driver is bad – it could mean that X-Plane sent the driver junk data. Or it could be the driver’s fault. We don’t know.)
Unfortunately that means that for the vast majority of 64-bit crashes, we have no idea what the sim was doing when it crashed – the trace from the driver will contain junk. All we know is that we were, in fact, in the driver at the time of death. (We also have the log.txt but often it just indicates the user was flying.)
This is a long term problem that we need to address as developers with our crash report technology; we have some ideas on how to fix it but they will take time to implement. Clearly we’ve hit a point where the low hanging fruit (crashes that affect a lot of users but are entirely in X-Plane code) are gone.
Coping With Add-On Crashes
We do not have good statistics (yet) for what percentage of submitted crashes were on X-Plane installations heavily augmented with add-ons, but it is not uncommon to see a user with a custom aircraft running a custom plugin, an online flight plugin, tons of custom scenery packs, and general utility plugins.
This kind of customization is great! We wouldn’t have added the SDKs if we didn’t want people to use them. But when it comes to isolating a crash it does make things quite a bit more difficult.
My goal for X-Plane is to not have X-Plane crash due to bad third party add-on data, no matter how badly it is formed. To that end, when I find cases where bad data will crash the sim, I am adding code to protect, document, and shut down based on the error. (Some errors are recoverable, some are not, but the important thing is to give the author some feedback as to what is going on.)
In the long term I think we need to add better diagnostics to our crash reporting to show what add-ons are involved in a crash. If you have 1000 scenery packs, I can’t go download them all in an attempt to reproduce a crash.
In the short term, if you are seeing instability and you have third party add-ons installed:
- Please run without the third party add-ons – the goal here is not to have a more boring flight, and it is not a cure – it is a diagnostic tool.
- By running with different sets of add-ons you can isolate which add-on causes a problem with a given flight.
- If you find a problem with a plugin (whether it’s in an aircraft or the add-on itself is a plugin), you probably need to contact the plugin author – the plugin contains its own code that we don’t have source to.
- If you find a problem with data (e.g. a scenery pack or airplane without plugins), please file a bug, including where to get the scenery pack or aircraft, and how to reproduce the bug.
Reproduction steps are gold to us! The combination of the add-on and simple steps to reproduce let us find and fix problems, even with third party add-ons. If you have a flight that crashes, please try to simplify it. Try going directly to the location that you were at where you crashed, starting with the engines on, etc.
Yosemite
While we’re talking about stability, I have to mention Yosemite: on OS X the vast majority of bug reports we’re getting that involve “weird stuff” and crashes involve Yosemite. We’re still trying to sort out the issues, but Yosemite is definitely the most disruptive OS X major version release we’ve had in a long time, and because it’s free, a lot of people downloaded it.
- If you haven’t updated to Yosemite on you’re using X-Plane, consider waiting until things settle down. We’ll work around problems, and Apple will issue patches.
- If you have an older machine, consider never updating. Perhaps this is heresy but often the maximum OS version your machine can run is limited by hardware requirements, e.g. this is the OS that just about knocks your machine over. How well is it going to run X-Plane? How much of the hardware resources are left for us?
- When a new OS comes out, don’t just click “download” even if it’s free; wait a week or two and see how well it works for other people first.
A major OS upgrade is when the OS vendor can make major changes, drop old technology, etc. On OS X it also means new OpenGL drivers (because the drivers are always packed with the OS), so it’s a potentially disruptive update.
Update: it turns out Yosemite also broke our automatic crash reporter, which would explain why none of the common Yosemite crashes show up in our top crash list. 🙁 Some users have sent me the Apple crash reports that appear (since our crash reporting doesn’t run) so that we can diagnose what’s going on.
Next Steps
10.31 should be out in a day or so (including Steam); as we continue to find and fix stability problems we’ll continue to issue small patches. We’re looking to do a 10.35-type release with small features and new airports; the current plan is that Julian and Tyler will do a public beta of the new airports (as a single separate scenery pack) so that people can try the new airports and spot problems before we get into beta.
* Crash reports don’t tell us how many times the sim was run overall; users with stable systems don’t send us any data, so an increasing crash report incidence would be meaningless – we don’t have data about increasing or decreasing use of the sim.
** Here we’re talking about true program crashes – the uncontrolled exit of the sim for unknown reasons. If you have a controlled failure, e.g. you load scenery and it’s missing objects and the sim refuses to run, you don’t get a chance to auto-report that. We also don’t view this as a stability issue – X-Plane can be very unforgiving about broken third party content, and we can have a separate argument about whether this is a necessary evil or terrible user experience (or both!), but there’s no diagnostic information to gather.
Update 2: Blog comments are now working again.
*** The problem is that for 64-bit there is no standard for back-tracing a stack without the debug symbols to decode the stack linkage; there is no standard link register. I’m guessing that the ABI designers thought they were helping the compiler guys optimize, but in practice it makes debugging other people’s DLLs miserable. Microsoft publishes debug symbols for every DLL they make ,which is a big help, but the driver writers do not.
Just a quick note: last night I fixed the bug in 1030 where the sky is corrupt when you use the instructor’s station and HDR together. This is the last of the ‘quick’ fixes for 1031, so I’m hoping to have 1031 cut over the weekend.
When I first saw pics of this bug I thought it might have been an old driver, but the number of users seeing it made it clear that it was a real thing; as it turns out, it was a subtle OpenGL screw-up by me. Frankly the amazing thing is that we’re not seeing it on every Windows driver. (From what I can tell, the AMD drivers “helpfully” work around my error, hiding the bug.)
We’ll post release notes with the beta with a complete bug fix list.
For about a year there has been a subtle bug in how X-Plane draws taxiways: if you build an S-curve shape out of a single bezier and it is almost perfectly symmetrical, X-Plane would go “nah, why bother” and replace it with a single straight line segment.*
So in 10.30 I fixed it, and the result was a bunch of broken airports with missing pavement. (YMML is high on this list!)
It turns out that these airports have authoring errors – typically a segment of pavement that should be straight instead being formed by two overlapping beziers. This is definitely wrong, but due to the bug, X-Plane would simplify the overlapping S curve into a single straight segment and the layout would work. Only now that X-Plane correctly renders the S curve does the taxiway fail (because taxiways may not have overlaps). So two wrongs may not make a right, but they do make a “hey, that looks okay, let’s ship it”.
Note that the overlaps depend on the rendering setting of X-Plane – a different S curve is formed at different rendering settings; the overlap that causes the taxiway to disappear may only appear at a particular rendering setting.
For 10.31 I am going to undo my bug fix. This doesn’t make me happy, but I think it is necessary:
- We have no idea how many airports have their taxiways broken by this bug.
- Authors have no easy way to detect this problem, other than re-testing every airport at every rendering setting.
- Even if an airport looks okay at all rendering settings, future rendering settings may cause the problem.
This is too much uncertainty to solve ‘by hand’. So my plan is:
- Undo the code change for 1031. YMML and friends comes back.
- Develop validation code in WED to detect this kind of authoring error.
- Ship that version of WED so new authoring work will be checked.
- Run the WED code on all airports and make a list of ones that need repair.
- Fix all of the known problems in the airport gateway.
- Redo the code change so X-Plane is correct.
This isn’t going to be a quick process, but then it can’t be, because third parties have apt.dats shipping now that only work when X-Plane has the buggy taxiway code in place. So we need to ship WED and then give third parties enough time to go back and check their layouts and fix them if necessary.
I expect to get a 10.31 beta with the taxiway code changed back this week.
For WED validation, I have some test code to detect errors but it isn’t ready yet. The problem is that it’s not good enough to detect errors with overlapping beziers**; we have to consider two bezier curves near enough to each other that with the error in rendering introduced by WED’s rendering settings, we get an overlap. (So authors, better be safe than sorry in creating your pavement.)
If there’s a moral to this story, I think it’s this: when we (LR) don’t provide good tools for authors to validate that their work is correct, the resulting body of work will end up with subtle errors.
* X-Plane renders beziers by measuring how far the mid-point of the curve is from the average of the ends. As long as this distance is ‘too far’ and the iteration count isn’t too high, X-Plane divides the bezier in half and repeats the process. In this way beziers are broken into enough line segments to approximate the bezier within a minimum error limit. The rendering settings control the error limit.
The bug: if the curve was a ‘balanced’ S curve the mid point of the curve was the average of the end points and X-Plane went “great, no error” and stopped dividing.
** Which is already not an easy problem – the analytical solution for bezier intersection is a 9th order polynomial!
As many of you are aware, we have been showing custom versions of X-Plane with support for the Oculus Rift at different shows and conferences. Naturally you want to get your hands on it as quickly as possible, and some of you have engaged in lively discussions on the forums and in the Steam community, which is why I’d like to give you a quick update on the current state of development.
First of all a big “thank you” to Bob from RC Simulations, who provided us with a DK2. His order was in the first batch, and he generously lent it to us until ours got delivered a few days ago.
The good news is that my DK2 now sort-of works with X-Plane on my Mac and PC. Now hold your breath, because the “sort-of” is an important part of the story. The bad news is that Oculus recently introduced some fundamental changes into the way the display of the Rift is exposed to the operating system. The changes were quite disruptive and haven’t even made it to Mac and Linux yet.
The latest SDK from Oculus comes with a proprietary display driver for Windows, to allow for a smoother display with less motion blur because it runs at 75Hz (instead of the 60Hz of virtually every computer monitor nowadays). This driver apparently works okay for Direct-X based games, but doesn’t work at all with openGL applications like X-Plane. For Mac and Linux, not even an unstable driver is available as of now.
On Windows, if we try to use the low-latency “Direct-to-Rift” mode, we get a Blue Screen of Death. It is a well-known problem of the latest Oculus SDK, that it doesn’t work with openGL. Any title with native DK2 support you find out there runs on DirectX, which also means it is a Windows-only title.
A user on the org forum posted this Star Trek quote:
“The needs of the many outweigh the needs of the few” (or “the one”).
suggesting we should’t wait for Oculus to provide Mac and Linux support and instead release a Windows beta RIGHT NOW.
In case it’s not entirely clear from I wrote above, the platform availability is not the problem! Even if we were to release Windows-only, we’d still need working openGL support in the Oculus display driver.
Using the DK2 in “Extended Desktop” mode like the DK1 is not really an option. Due to the DK2 running at 75Hz, and your primary monitor at 60Hz (unless you still have one of those heavy CRT monitors) you will get terrible vsync. It is dropping frames left and right (regardless of your actual frame rate!) causing what people on the Oculus forums refer to as “DK2 judder”. In fact, DK1 looks better than DK2 right now, given we can only use the “Extended” mode, and that is just lame.
I am heading out to Oculus Connect later this week, where I hope to get some insight into the what and when of openGL support, the roadmap for their drivers and if we are ever going to see native DK2 support on Mac and Linux.
As of now, I have to tell you that for anything but DirectX-based games, the Oculus SDK is so beta that it is not even alpha. We will have to wait for future versions of the Oculus SDK to fix those issues.
Last year with X-Plane 10.25 we began to share 3-d lego brick airports. X-Plane 10.30 adds more, and with the X-Plane Airport Gateway now live, I’m sure we’ll have even more 3-d airports in the next update.
One thing this means: conflicts between payware airports and the global airports that ship with X-Plane will become the norm, not the exception. This blog post describes how to keep payware and the global airports from getting into each other’s hair.
Prioritization of Scenery Packs
X-Plane scenery packs are loaded in priority order; in order to ensure that you see your payware, the payware must be higher priority than the global airports. The system for prioritizing scenery packs changed in X-Plane 10.20, so please read this carefully!
Scenery packs in “Custom Scenery” are loaded in the order of scenery_packs.ini. Custom scenery packs at the top of the .ini file are loaded first and override packs below them.*
Any time X-Plane runs and finds a scenery pack not in the .ini, it adds it to the top of the file; therefore when you install new scenery, it starts at the highest priority level. Usually this is what you want.
The airports from the X-Plane Airport Gateway are in a scenery pack called “Global Airports” in your custom scenery – this pack should be higher priority than any base meshes but lower priority than any custom airports.
Exclusion Zones Are Needed
The runway and taxiway data for an airport comes from the highest priority scenery pack that includes that airport in its apt.dat. But 3-d objects are overlaid in an additive manner; in order to avoid conflicts between two sets of 3-d objects, the higher priority scenery pack must include one or more _exclusion zones_.
An exclusion zone is a rectangle in an overlay DSF that tells X-Plane to remove any 3-d in that area from lower priority packs. It lets an author “clean out” an area for later use.
Authors: all custom airports should be built with exclusion zones to protect them from other custom airports and the global airports that ship with X-Plane. If you are working on an airport and there is no 3-d in X-Plane, include an exclusion zone anyway – 3-d may appear in an update.
Users: if you have a custom airport and it does not have exclusion zones, all is not lost. Until the author updates the custom airport, you can do the following:
- Build a scenery pack that contains _only_ an exclusion zone over the affected area in WED yourself.
- Prioritize your scenery packs as follows:
- Payware – unmodified
- Your own “Exclusion zone”
- Global Airports – unmodified
Your exclusion zone pack will filter out 3-d from packs “below” it (including the global airports) and leave your payware clean and unobstructed.
Things Not To Do
There are a few things I strongly recommend you _not_ do in trying to resolve scenery conflicts:
- Don’t modify, rename or delete the scenery packs that come with X-Plane. The updater is just going to try to restore them every time there is an update. You’ll be pushing the rock up the hill over and over again. Don’t delete individual airports out of Global Airports – the installer will just put them back.
- Don’t constantly delete scenery_packs.ini. Some users have told me that they like to rename their folders to alphabetical, delete the .ini file and let it rebuild each time. But this violates the renaming rule and means updates won’t go well. Edit the .ini file to get things the way you want – it’s there for you to customize.
* Why did we pick this? The old way of customizing scenery packs (renaming them) didn’t work well with our updater – the updater would see the scenery pack (under its original name) gone and re-download the pack, wasting time, bandwidth, and creation chaos in the custom scenery folder. The scenery_packs.ini file lets users disable and re-prioritize scenery packs without having to rename anything.
I heard quite a bit from the cloud and weather tweakers when we started 1030. At the beginning of the beta, I thought I’d have the visibility and fog improvements ready to go, and so I posted about possible changes.
Those features got pushed out to a future patch. The cloud lighting did change. So what was the total set of changes?
- Scattering and lighting did not change, and there are no changes to art controls. So hacks to atmospheric scattering are unaffected.
- The format (size, color format, usage) of the cloud textures did not change – if you have a replacement cloud texture set, you can keep using it.
- The actual default cloud textures did change – I beat them up a bit in PhotoShop. Hence if you have custom cloud textures installed, the updater will yelp.
- The lighting and placement of the cloud puffs has changed, so color choices for custom textures may have to be revisited.
- Art controls to kill clouds are still there – but if you want our clouds gone, use the new override_clouds dataref!
- There are new art controls controlling the (now redone) white-out effect.
So the total impact on cloud and atmosphere tweaks should be relatively low – but the lighting definitely changed on cloud puffs.
My expectation is that when the scattering art controls change (and they will change someday) it will be due to a change in the scattering code itself that will be “worth it”, e.g. a major iteration to improve the look of scattering itself.
Update: several people have volunteered, and the installers are now tested – thanks!
One of the remaining bugs in 1030: when you install a 1030 update after having received DSF recuts (e.g. the update from 1030b8 to 1030 RC 1) the Aerosoft custom EGLL pack disappears.
It turns out this is a bug in our installer/updater – the bug has actually been in the installer/updater for a long time but normally didn’t act up (unless you modified your installation in some very unorthodox ways).
I am working on a new rev of the installer (3.22) that will fix this. But I need Linux volunteers to test, especially the 32-bit edition. If you can run 32 and 64-bit apps on Linux, please email me (ben at x-plane dot com) and I will set you up with test apps.
There are a few straggling bugs that we’re hoping to fix in RC2 this week.
Update: I totally forgot this announcement for Linux users*: the new 3.22 installers come in 32 and (for the first time) 64-bit flavors.
This means that with X-Plane 10.30 and the new installer, all X-Plane apps come in a 64-bit app, and you don’t have to install multi-arch gunk on your 64-bit Linux install to run X-Plane.
We will continue to support 32-bits on all platforms for the lifetime of X-Plane 10, and the installer, Airfoil-Maker and Plane-Maker will remain 32-bit on Mac/Windows, where 32 bit support is guaranteed without any hassle.
* This is what happens when I sleep even less than normal. You can only imagine how good these installers must be. 🙂
