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.
Hi Guys, it’s Chris. I haven’t written a blog post in ages. They’ve kept me locked in the basement like Milton Waddams, unwilling to let me out to see daylight until I finished X-Plane 10 Mobile. And they stole my #$%#^ stapler!
We recently released X-Plane 10 Mobile for iPhone/iPad and while the Apple users were ecstatic, some Android users were puzzled while others were frustrated.
“Will there be an android version?”
“When’s it coming to Android?”
“Where’s the Android version? 60% of all smartphones run on Android but I guess that Apple-Fan-Boys are more important in your company”
“Why do you guys constantly focus on iPhone first when most users are on Android?”
Before I get into the real point of the blog post, allow me to answer some of those questions. YES we are planning on shipping X-Plane 10 Mobile for Android. YES we have already begun development. We do not have a release date. We do not have any hints. The only thing that I can say, is that we want it out just as soon as you do. NO we do not view Android as a lesser/inferior platform…We value Android customers just as much as we value our iOS customers. A customer is a customer. I think we’ve demonstrated by supporting Windows, Mac and Linux all these years that we’re not trying to play favorites. We want everyone to be able to enjoy our products. BUT, that doesn’t mean that the costs of development and the speed and efficiency of development is equal on all platforms.
Historically, we’ve always developed for iOS first and then Android second. I’d like to be open an honest about our reasons and hope that even if you disagree with them, you’ll at least understand why we have historically developed for Apple first. I will warn you, everything I have to say is completely my opinion, my impression, my feeling based on my experiences. I’m going to sound a lot like an Apple “fanboy”. I will admit, I do have a high level of respect for Apple’s commitment to polish and detail, but I also own a dozen android devices and respect them for their cutting edge features, their openness and their friendliness to customization.
At the end of the day however, I’m paid to be efficient and thorough and my thoughts below explain why that means Apple has historically come first.
I will also warn you…I don’t want this blog post to turn into a flame war between Apple and Android users. We’re talking about phones here people, not religion. At the end of the day, they’re just small piles of plastic and silicon that let us surf the web, make phone calls and play games.
We Can’t Develop Apple and Android In Parallel
Sure, we do this on desktop by releasing Windows, Mac and Linux versions in unison 100% of the time. Developing for desktop is pretty different than developing for mobile. We use very few 3rd party frameworks on desktop and it’s an open environment. On a mobile phone, it’s a very closed environment. What this means is that developing Apple and Android in parallel requires a lot more effort than developing for Windows and Mac in parallel.
Can it be done? Absolutely! Plenty of companies are doing it. But they also have large teams with large expenses. We’re still a pretty small group of individuals and we like it that way. The tradeoff however is that we can only focus on one platform at a time.
One alternative that we could consider is delaying shipment of an Apple product until the Android version is done as well. That’s a loss for everyone. Apple customers lose out on having the latest software and Android customers may lose because…we don’t have the revenue coming in to support the Android development costs. That’s right…Apple sales get reinvested into the company to fund Android development!
As Ben mentioned earlier…Apple and Android mobile sales fund desktop development…and desktop development funds mobile development! This is a very important fact to remember. I’ll admit, we laugh and roll our eyes when desktop users complain about the company working on mobile products, and mobile users complain about the company working on desktop products….and android users complaining about us working on apple products and vice versa.
The company has found equilibrium creating both desktop and mobile products. There’s adequate revenue to fund adequate staffing to continue to develop both.
We Develop On Mac Hardware
This is no secret. It’s been this way since the company started. We just find Apple products allow us to be more productive and don’t get in our way.
Historically, Apple’s Mobile Platform Has Been More Mature
Apple had both a technological advantage as well as a time advantage over Android when they began.
Apple already had an Operating System, supporting frameworks and a development environment to leverage. Making mobile versions of those things required them to port existing, time-tested code to a new platform. From a stability standpoint, Apple had the advantage in that they already had the code, the engineers and the process in place to do this.
On the other hand, Google had to start from scratch. They had to put together a new team to create a new operating system to run new frameworks…and they had to create a set of tools for developers to use.
In addition to all of the technological advantages Apple had, they also had a head-start of well over a year. We were already selling X-Plane V9 for mobile before Android was even announced publicly.
That meant we were already established and familiar with the iOS platform as developers.
When I began the Android port for X-Plane V9, I had to pretty quickly put it down…and wait. Android at the time only supported Java apps. X-Plane is NOT a Java app. 99% of it is written in C/C++ and Android had absolutely no support at the time…and so we waited….and waited….and waited.
Finally, many months later, Android added their NDK which allowed us to have C/C++ support. But it was completely minimal. None of the standard libraries that we were used to using were available. This meant a lot of effort on our part to get anything done. If you’re not a developer, a reasonable metaphor might be a carpenter that’s trying to build a house, but he first has to build his own hammer, nails, square and saw because the tools he’s used to using don’t exist on this job.
Finally it came time to release V9 for Android. For iPhone/iPad, we uploaded our 400+mb app to their store and we were done. On Android however, the store had a limit of 25MB. So that meant we had to buy servers and write code to download the resources from a farm of servers. Again, this added more time and more complexity.
Apple Has Fewer Devices
For this latest release of X-Plane Mobile, we support iPhone 4S/5/5S/6/6+ as well as iPad 2/3/4/Air/Air2/Mini/Mini2 and iPod Touch 5. That’s 13 devices to my recollection. But it’s even simpler than that…because they all have the same GPU manufacturer, they all support the same PVR texture compression, and they all pretty much just work interchangeably from a development standpoint. The only major differences between them are the processor speeds and the screen resolutions. We can literally test on every single device and be sure that the app runs the way we expect it to.
As of the time of this writing, our X-Plane V9 is running on 7,072 devices. You read that right….SEVEN…..THOUSAND…..DIFFERENT……DEVICES. Each device has a different combination of CPU, GPU, screen size, screen density and drivers. We cannot possibly test them all. Admittedly, many of them “just work” and there are of course only a handful of CPU and GPU manufacturers to worry about…but at the very least, it means at least three different texture compression formats. PVR is proprietary and unless the mobile device has a PowerVR chipset, they’re not going to get PVR. So we have to support various formats. That requires three different versions of our app to be created and tested and distributed. That requires three different resource packages to be created and tested.
There’s just no way to have the same level of stability as we can have with the iPhone/iPad platform.
Apple Has Higher OS Upgrade Adoption
Without carriers and other manufacturers getting in the way, Apple can release a new OS with features and bug fixes, and we can be sure that they exist on the majority of the devices that we care about in no time. This means that if there’s a driver issue that needs fixing, it will make it out to the masses and eventually the problem is gone.
Android’s fragmentation has really hurt them in this area. We encountered several devices over the years that violated some OpenGL spec. We worked with the manufacturer to isolate the issue. They release a patch to fix the issue…and most users never had a way to get the patch because their phone carrier dropped support for that phone model.
Now the user’s stuck with an App that they paid for that doesn’t work and there’s nothing that we can do about it.
We like Apple’s Developer Tools Better
As I mentioned earlier, Apple’s developer IDE has been around for ages. We have access to various performance analyzers and can now even analyze an entire OpenGL frame, one draw call at a time. This means we can really tune the crap out of the app before we make it public. In addition, all of the tools come in a single package that just works out of the box. Apple has also always had a simulator that’s hardware accelerated. This means for a lot of things, i don’t need a device plugged into the computer to debug something.
Android’s solution was for less “out of the box” in that they were using various open-source pieces that all had to be installed and fit together just right. Android had an emulator that was not hardware accelerated. It took longer just to boot than it took me to find a phone in my house, get it, plug it in and push an app to it.
Honestly, I think both sets of IDEs are sorely lagging behind features that Microsoft’s Visual Studio has had since 2000, but I digress.
TL;DR
We develop for Apple first because it’s easier and faster for us. It allows us to get the product out the door, running as efficiently and as reliably as possible. When we port the app for Android development, we can be sure that most bugs that come up are specific to Android and are therefore much easier to resolve in a timely fashion.
We are not playing favorites. We have no personal issues with Android and have no personal ties to Apple. The day that Android becomes the faster and easier platform to develop for, it will be the one that we develop for first. It’s just a business decision!
In the meantime, Android users should remember that the way things are currently being done means that they sometimes have to wait longer for new updates, but the updates that they receive will likely be more stable as they’ve been tested harder.
I will also note that we are closing the time gap between iPhone and Android releases. In the past, we were over a year behind on the Android release…because Android didn’t exist. 🙂 Now that it’s becoming more established, the gap should be shrinking more and more.
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.
