It’s very simple: if you want to file a scenery bug, it goes to the bug report form if it is actually a problem with X-Plane or the implementation of X-Plane’s core libraries. If the functionality actually needs to go into WED it goes into the public scenery tools code base, but if it’s a problem with the existing airport data, it goes into the X-Plane Airport Gateway bug database. Plugins have their own bug database. Simple, right?
Given the above, I can’t really be annoyed when authors, developers and users file their bugs in the wrong place. We have five bug databases running now, some public, some private, using three different bug database packages on at least three different servers, implemented in three different back-end languages.
The good news is: Tyler is creating the one bug database to end all bug databases.
Now, if you fly X-Plane and you don’t develop add-ons and you don’t create airports at the airport gateway, I won’t fault you if you don’t care at all. The rest of this post is going to be an (even more) boring discussion of bug databases. Go look at pictures on airliners.net; I won’t fault you for not finishing this post.
For the three of you still here: basically we are creating one unified bug database. The bug database is mostly private (to meet our internal development needs) with a front-end with variable access for authors to contribute. Bugs on some products will remain totally public (e.g. scenery tools), some bugs will private, and there may even be bugs where you can only see what you filed, a la Apple’s “Radar” bug filing system.
Gateway Airport Bugs
This all started when Tyler built a bug report system around the X-Plane airport gateway; it lets you use your airport gateway identity to report bugs on gateway airports. Thus a front-end to a real bug database was born. The front-end lets you have a single user log-in for both uploading airports and reporting bugs.
Scenery Tools Bugs
Tyler has now begun the next step: merging the scenery tools bug database into the new bug database. Thus the scenery tools bug database is temporarily closed to new submissions. All existing bugs will be transferred, but if you don’t have a gateway login you’ll need one to file future bugs.
The scenery tools bugs will remain fully public; the code repository is open source, so the bug base should be as well.
A small number of users have direct access to the scenery tools code repository, e.g. they contributed enough that we gave them their own set of keys. Those users will get direct bug base access as well; however, I think in the long term the front end will include all of the functionality that almost all users will need.
I’m hoping that the migration will be complete within a week or two, and be ready for WorldEditor 1.4 public beta.
Plugin Bugs
The X-plane plugin system has its own bug base; if the scenery tools bug database merge goes well, we’ll merge plugins next. The plugin bug base is a public bug base, like scenery tools, and will probably remain that way.
X-Plane Bugs
I don’t know what we are going to do with X-Plane bugs. The current bug report form does not go directly into our bug base, and I continue to say that that is a good thing: way too high of a percentage of the “bug reports” we get on X-Plane itself look like this:
Help! I just bought X-Plane 10 and it does not work; when I fly I do not see anything! Please help!
Steps to reproduce: Fly the sim!
If you have experience in software quality assurance, you can understand why I don’t want “bugs” like that piling up directly in the bug database; most of the bug reports have to get forwarded to customer support.
There is a bug in 10.32r1 Steam Edition – some kind of interaction between Steam and Gizmo causes Gizmo to crash. Since Gizmo is loaded on startup, this means users of popular add-ons like Skymaxx Pro can’t fly.
We are working on this now and I am hopeful we’ll have some kind of fix tomorrow. I’ll also post more details about the bug once we have more info. The crash affects X-Plane 10.32r1, Steam edition on OS X only, as far as we know.
In the meantime: if you get a crash on start with X-Plane 10.32r1, please file a bug. Please include your Log.txt file and any crash logs that you see go by. In particular, if a plugin is having problems only on the Steam edition (but not the Global edition of 10.32r1) or if a plugin besides Gizmo crashes, I would like to see it!
UPDATE: We have determined that the crashes are caused by Steam introducing an ABI breakage of the libstdc++ runtime when we use one of their distribution tools. We are now working with an engineer at Valve software to solve this. In the meantime, the Steam distributed X-Plane has been rolled back to 10.31.
UPDATE 2015-01-21: Thanks to quick help from Valve software, we were able to re-release X-Plane 10.32r1 on Steam today which now gets along fine with plugins again.
X-Plane 10.32 is now final – you’ll get an auto-update message when you run X-Plane.
Coming soon:
- 10.35 – we still have code to put the finishing touches on, but the plan is to release more Gateway airports in 10.35. This will not be the last gateway release (obviously 🙂 so if your airport was approved too late to make the cut, we’ll try to get the next release out soon. (Our goal is to keep gateway airports flowing rapidly so that everyone can get the full benefit of everyone else’s work easily.) I am hoping for public beta within a week.
- WED 1.4 – will include GeoJpeg2000 image support, improved orthophoto overlay creation, and importing directly from the Gateway. Again, I am hoping for public beta within week.
If you would like to know the status on the Oculus Rift, I suggest you comment on this post (even though it is off topic), any other post that is still open for editing, and every additional post we make (no matter how off topic) until Philipp posts an update; while he has not responded yet, he did assure me that he will make a statement if he gets at least 275 off-topic comments on the Rift.*
* This last paragraph is completely false, just another case of me being snarky and poorly behaved on the interwebs.
The real number is 374 posts. 😉
WorldEditor 1.4 is almost ready for beta, and among its new features (there are several big ones) one is very important to the X-Plane Airport Gateway:
- WED 1.4 can browse airports on the gateway and download scenery packs directly into the WED workspace.
“Direct download” is really important for a few reasons, some of which might not be obvious:
- It saves time. Getting a gateway airport, even if you just want to look at it, is much faster when you don’t have to download the scenery pack, unzip it, install it, then import it into WED. Once you use direct download, you’ll wonder how you lived without it.
- It prevents mistakes. We have seen airport submissions where a user clearly downloaded a scenery pack, imported only the apt.dat (but not the DSF files) and then uploaded it. We cannot take scenery packs like that, because they fundamentally remove the 3-d data from the airport. (A fundamental policy of the gateway is that if you upload a scenery pack and one already exists, yours can’t be worse than the existing one in some way. We have to always move forward.)
- It provides ancestry information. When you download and then upload directly from the Gateway in WED 1.4, WED provides the scenery pack ID of the original pack as the “parent” of the new pack. This means that when Julian goes to look at an upload, he can look at the “original” and more rapidly spot problems. If your pack is the same as the original except for taxi signs, he only needs to inspect taxi signs.
- It prevents data loss. DSF is a slightly lossy data format – that is, if you get your data back out of a DSF file, it won’t be exactly the same as what you put in. (It is like a JPEG image in that regard.)
More on that last point: DSF stands for Distribution Scenery Format – it was meant as a way to make final scenery packs; it was not meant as an interchange format for continuous editing. So users are constantly importing and exporting DSFs to do work, small rounding errors (“bit rot”) will creep into our 3-d, and features that were perfectly aligned might not be well aligned after 4 or 5 edits.
The internal format for scenery on the gateway is not binary DSF files, so doing round trips to the gateway has much less “bit rot” than importing scenery packs.
Finally, DSFs are tiles; if your airport spans a DSF boundary, all DSF features (polygons, fences, etc.) get split along the DSF boundaries.
So if you import a scenery pack that you downloaded, you’re getting the split version, which is harder to edit and work with.
The internal format of scenery packs on the gateway is not split, and thus you can edit the original in almost the same form as it was uploaded.
WorldEditor 1.4 beta should becoming in “weeks” (and hopefully not that many weeks); I’ll post here when we are ready for beta testers.
X-Plane 10.32r1 is now available to beta test – to get it, run the updater and click “get new betas”. Release notes here.
10.32r1 is another small patch aimed at fixing critical bugs. Hopefully soon (E.g. in a week or two) we’ll start a beta of X-Plane 10.35, which will contain new airports from the X-Plane Airport Gateway, as well as smaller feature enhancements that people have asked for.
Right now it looks like fixes for Yosemite will go into X-Plane 10.35 and improved DSF loading and longer DSF visibility will go into X-Plane 10.40 if the code is solid enough.
I want to link to two scenery add-ons that are now available for X-Plane 10:
Alpilotx’s HD Scenery Mesh version 3 is out now. There’s a bunch of good stuff going on here:
- The mesh quality is cranked way up. If your machine can handle this, it makes the DSFs look a lot better.
- This is a recut from the latest OSM data, so the scenery tends to be more accurate. If there’s a tile that’s funky in the default sim, an HD tile replacement can be a nice fix.
- Alpilotx includes details that don’t go into the global scenery for space reasons – better water definitions, more exact forests, etc.
(The blue-ish atmospheric coloring is a third party add-on that Alpilotx installed that cranks up the atmospheric scattering strength.Edit: Alpilotx tweaked the atmospheric scattering himself using a Lua script – see here for more info. But there are third party add-ons that do this if you don’t want to roll your own.)
XFlyer’s Winter Package 1.1 – I’ve been meaning to post this, and it’s a great add-on to combine with the HD meshes.
This add-on replaces the terrain textures with winterized versions. The picture links to some forum posts showing the pack in a number of conditions.
Unfortunately installation of seasonal add-ons is still trickier than add-on meshes, something I hope to fix relatively soon. You’ll find installation instructions on the .org link.
Posted in News
by
Ben Supnik |
We finally shipped X-Plane 10 Mobile! Here’s the official press release:
Laminar Research, creators of the X-Plane flight simulator franchise, has announced the release of X-Plane 10 Mobile, the premiere flight simulation product for the iPad and iPhone.X-Plane 10 Mobile was built using the same concepts in Laminar’s showcase desktop product, X- Plane 10. As with the desktop version of X-Plane, the mobile version utilizes real physics to model the aerodynamic forces found in flying an actual aircraft. The result is a product that is not just another game, but rather a highly sophisticated simulation of how aircraft actually behave in a variety of environments and weather conditions.Version 10 contains numerous features and enhancements not found in the previous mobile version of X-Plane, including:
- 2-person multiplayer over the Internet
- Many additional aircraft – – from a Piper Cub to the Airbus, and it even includes combat aircraft and a helicopter… all with 3D cockpits and available as in-app purchases
- Challenges – – over 20 scenarios including engine failures, mountain top landings, birdstrikes, and even airstrikes, where you dodge incoming anti-aircraft guns missiles
- Flight School tutorials – – including the basics of takeoffs & landings, flying traffic patterns, and how to bomb ground targets
- Brand new, modern user interface – – designed just for mobile devices
- Improved combat system- – – with better missile guidance, more accurate weapon simulation and more realistic explosions
- Realistic airport environments – – including airport buildings
X-Plane 10 Mobile is available as a free App on the Apple iTunes Store and includes a free Cessna 172 starter aircraft. Additional aircraft may be purchased using the in-App purchase feature. An Android version is also scheduled for future development.
We also managed to DDOS ourselves by creating so much traffic back to the company website with the initial announcement, but the site’s back up and stable now. (The developer blog is on the same server as the main website, so if the server’s getting killed again, you’re not reading this. 🙂
Posted in News
by
Ben Supnik |
TL;DR version: if your plugin runs on OS X, you you should be setting the capability “XPLM_USE_NATIVE_PATHS” to 1, like this:
XPLMEnableFeature("XPLM_USE_NATIVE_PATHS",1);
This sets your plugin to use Posix-style file paths on OS X.
I am going through X-Plane looking for APIs that Apple has deprecated and replacing them. Aliases to custom scenery on other hard drives stopped working in Yosemite because we were using the Alias Manager to resolve the aliases, and the API is deprecated; in Yosemite Apple actually made it stop working. So now I’m looking to see what other deprecation problems we might be sitting on.*
One thing I noticed in my search is that kCFURLHFSPathStyle is marked deprecated in OS X 10.9. I don’t know when it will actually stop working, but we’re not supposed to be using it.
And here’s the thing: the only use case we have for it is incredibly silly: if your plugin doesn’t tell us that you can support Posix paths, we’ll convert to HFS paths so that you can then (in your plugin) convert back to Posix paths. In this use case, both the XPLM and your plugin are using a deprecated API to temporarily convert a file path to a silly format, and then back again.
Why Are Unix Paths Opt-In
The original XPLM API dates back to X-Plane 6 and ran on the classic Mac OS under the HFS file system. In this environment, all file system paths were HFS paths, e.g. Volume:directory:then:filename.
For a while, X-Plane could run under OS 9 and OS X using the Carbon APIs and CFM file formats; in this environment, the SDK continued to provide HFS file paths to all plugins at all times.
When we introduced the ability for plugins to use the underlying Posix file paths (which makes life much easier for the plugin developer, since Posix paths are what the OS really wants) we had to make it opt-in; a plugin tells us it wants this new thing by setting a new feature. Plugins that don’t opt in are assumed to be old and are assumed to expect the old convention.
HFS Paths Are Now Obsolete
Here’s the thing: at this point Apple has changed ABIs twice and changed CPU architectures; they have also changed executable formats. Simply put, no plugin code that runs in X-Plane 9 or 10 can possibly be using HFS file paths directly, because all running plugins are only capable of running on OS X.
But because it was possible to write a plugin that worked both ways (by opting in only when X-Plane was ready) there are still plugins that will run in HFS mode if and only if X-Plane can’t support Posix (e.g. if they are running on X-Plane 9.)
So in order to fully dispose of HFS paths, we need your plugin to start opting in to Posix paths. Doing so is really easy – it generally involves adding the one line above and deleting your HFS code (which is fun).
When Can You Use Posix Paths
Posix paths in the XPLM are available to plugins starting with X-Plane 10.0. If your plugin requires X-Plane 10 or the XPLM 2.1, posix paths are always available.
The XPLMEnableFeature APIs are available to plugins with the XPLM API 2.0, starting with X-Plane 9.0. So if your plugin only runs on X-Plane 9 and 10, you can attempt to set this (because the API is always available).
* Because our minimum OS is OS X 10.6 for X-Plane 10, X-Code normally doesn’t tell us about most deprecations. To find all of the issues, I temporarily set our minimum to OS X 10.10 just to see the warning list.
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.
