I’ve posted a number of times on the transition to 64-bit, we have release notes and a FAQ, as well as a number of tech notes for plugin developers, but in this post I want to cover how I see the community moving over to 64-bit.
64-bit is a fundamentally confusing issue – it’s one of those things that should be totally transparent to computer users, but due to the nature of code and plugins, 64-bit is not transparent. So more explanation will hopefully at least not confuse the issue even more. Maybe.
Is a Transition to 64-bit Even Necessary? Does it Have to be Now?
The short answer is yes. 32-bit applications simply cannot take advantage of more than 4 GB of physical memory (among other limitations). Every year CPUs get faster, people get more cores, GPUs get faster, GPUs ship with more VRAM, and every now and then we even get a faster PCIe bus. During this time hard drive, SSD and RAM prices continue to fall. You can bring your computer up to 8 GB of memory (Crucial memory – good stuff!) for $34. But what’s the point if the app you are feeding is 32-bit?
In other words, the march of hardware is unrelenting, and if we want X-Plane to be able to use the full power of our computers, we have to go to 64-bit.
How soon do we need to go to 64-bit? Mac users who like add-ons have been crammed up against that 32-bit ceiling for a while now, while Win 7/64 users mostly still have some headroom. But the real question is: could we finish out a major version run in 32-bit? Could we wait years to go 64-bit? I think the answer is no. Even if we didn’t care about the RAM limit on Mac and Linux* 64-bit will become a Windows issue too; it’s only a matter of time, and I suspect not that much time.
The Phases of Adoption
This is how I see the migration from 32-bits to a 32/64-bit world going:
- Beta. That’s where we are now. In this phase, 64-bit technology is unproven even in the sim itself. Plugin developers are hopefully trying the 64-bit betas and looking for major critical bugs, but 64-bit isn’t useful for actually flying. (Well, the sim is beta, and I never recommend flying on the beta.) I don’t expect anyone to ship a 64-bit add-on during this phase.
- Crossover. Once X-Plane 10.20 goes final and we have a stable 64-bit build that third party developers can actually test against, we’ll have a phase where some add-ons come out in 32/64-bit formats and others are not yet ported. The length of this phase will be the difference between the fast and slow add-on developers; different plugins will take different time to port, have different levels of complexity, etc. During this phase, users will have to pick 32-bit for compatibility or 64-bit for memory use.
- Acceptance. Eventually we’ll arrive at a point where so many add-ons have been made 64-bit compatible that the norm and expectation is that all add-ons are 64-bit, and the community will mostly have to abandon add-ons that are not migrated forward.
Note that “acceptance” is not only after 10.20 goes final but there is an entire phase between 10.20 going final and being able to “just run all add-ons in 64 bit”. This is because it is going to take time for people to move their plugins forward.
32-bit Still Works!
I cannot emphasize this enough: there is a 32-bit build of X-Plane in the 10.20 betas, and it should just work! The switch from 32 to 64 bits is not a binary transition where we pull the rug out from under everyone in one swoosh and everyone scrambles. It is the beginning of a migration that can happen over time, while 32 and 64-bit apps areboth available to everyone.
* I have heard people tell us that we don’t care about the Mac just when it is surging, that we should drop everything but Windows, and that Linux is, in fact, the wave of the future. We’re going to hedge our bets and keep supporting all three. Having done the work to be cross-platform it doesn’t make sense to drop multi-OS support.
We have received a number of bug reports on the livery system in X-Plane 10, as well as complaints from both users and authors about how the system works. This post describes what I am thinking for liveries; if this proposal seems hair-brained, the comments section would be a good place to counter-propose.
Two notes on UI discussion before we jump into the details:
- We hate check-boxes. If the UI debate is “which is better, UI A or B”, then the answer is pretty much never “let the user pick A or B with a check-box”, because the point of UI is to present the program in a human-friendly manner. Having two different UIs with selection forces the user to become the UI designer, which is inherently harder. So while we don’t have zero check-boxes in our UI, we really try to keep the ‘have it your way’ stuff to a minimum; X-Plane is a product for sophisticated users and if we put in a check-box every time we get a request for one, the product would be absolutely unusable.
- In arguing for UI, describe what you want to do, not how you want to do it. If you describe an implementation but we can’t do the implementation, the discussion is over. If you describe what you want to do, we can find several implementations and pick the best one.
Liveries Now
As of X-Plane 10.11, you can:
- Select your livery when you open a plane using Open Aircraft…
But you cannot:
- Change the livery without reloading the airplane, mid-flight.*
- Select your livery from the Quick Flight dialog box.
- Change your livery quickly (since a plane reload is slow).
- Change which livery the QF dialog box picks for you – it always pick “no livery” (that is, default paint).
These first two bugs go hand-in-hand. Because you have to reload the plane to change liveries, you lose the initialization that Quick Flight may have done for you.
* There is one bug to note: if you go to the open aircraft dialog box, select a different livery and hit cancel, X-Plane will change your livery on the fly but not reload the plane. Some users have noticed this and use it as a back-door way to change livery mid-flight.
For 10.20
For the short term, I am converting the bug in the Open Aircraft dialog box into a feature – the dialog box will have a “change livery and keep flying” button to change your livery on the fly, and the “cancel” button will not unexpectedly change your livery. Thus the functionality of the old “open livery…” v9 functionality will be part of “Open Aircraft.”
This isn’t perfect, but it at least addresses the issues of changing liveries quickly, or changing them while flying, without having to know about and use a hidden UI bug.
For the Future
There are more features we’d like to do in the future:
- Have a dedicated livery-change UI again – perhaps one that ‘floats’ over the main window while you fly, so that you can see the liveries as you click on them. This would be a quicker way to rapidly preview a large number of liveries.
- Remember the last user selected livery in the per-aircraft preferences (along with quick-look keys) so that if you go to open an aircraft and don’t do anything else, we can pick the last livery you used.
- Someday have ‘drill down’ functionality in the Quick Flight window so that you can set more detailed info about your plane (livery, weight and balance, fuel, weapons) and then go back to the main QuickFlight window. This is a long ways off though.
None of this is going to make it into 10.20 – I mention it only to explain where we’re trying to go – the change for 10.20 are designed to not interfere with this future work. The future work is all based on user selected livery choice, with preferences an easy selection.
Livery Choice in Plane-Maker
This finally brings me to livery choice in Plane-Maker. I have always considered this a bit of a weird feature; it is inoperative in 10.20 and we are looking to get rid of it permanently – that is, setting a livery in Plane-Maker has no use in any of the above plans. Our view:
- The first livery you see if you first open a plane for the very first time in QuickFlight will be the default one.
- Preferences should record the users choice of livery, and this should be done entirely from X-Plane. It should not be necessary to open Plane-Maker to change livery preferences, any more than Plane-Maker is needed to change rendering settings or joystick preferences. User customization should be 100% in-X-Plane.
As I said before in the top of this article, if this seems half-baked to you, please describe what you want to do, not how you want to do it. And please understand that when it comes to UI, less is more; we need to identify a small, highly leveragable set of UI options to cover a wide variety of features. We don’t want to have 6 ways to do everything!
Two new add-ons out in the last few days:
The first is AlpilotX’s New Zealand Pro scenery. This is a recut of all of NZ using higher quality global data, the global scenery algorithms run at higher settings (no need to tone them down if the whole world doesn’t have to fit on 8 DVDs) and some custom GIS algorithms Andras came up with to handle various features.
For me it’s exciting to see what the engine can do when someone let’s it a bit off of its leash; the global scenery is always a compromise between the possible and what can be done for all users over the entire planet – it’s a compromise to make a base layer.
NZP is donation-ware. Andras* is not a Laminar Research employee – he is an X-Plane user who has gone so far with his scenery work that he works directly with us on the global scenery; we are very lucky to have his help — his contributions make X-Plane so much better, both when he works on the global scenery and on his custom work.
* Albert, who does the textures, is in this same category – they are two of a number of X-Plane users who have made outsized contributions to the sim!
Second, the McPhat ATR-72 is out. I had a chance to meet these guys in Mallorca, and see some of their work-in-progress and the stuff on their laptops was really phenomenal. I always enjoy seeing people push the envelope; it gives us an idea of where we need to provide more ‘headroom’ inside X-Plane.
On the subject of betas: I don’t know when beta six will come out – I think sometime next week but I don’t know if it will be early or late in the week. We do have a potential fix for the library problems with autogen (the 10.20b5 drop with new autogen is missing some library definitions) so that should help people using custom scenery who are getting the dreaded “could not load forest/facade/beach” message. (We changed our tools for the new autogen and accidentally lost some library paths which we are putting back.)
The old library did accidentally have a lot of library paths with the word “test” in them; I really hope no one is using them in their add-ons. As a general rule, if the word “test”, “temporary”/”temp” or “hack” is in a library path don’t use it!
Posted in News
by
Ben Supnik |
I probably should have said this earlier.
Please do not release 64-bit add-ons.
If you want to beta test your add-on in 64-bits, great! If you have gotten 64 bits working, that’s totally cool!
But, please don’t ship 64-bit code. The problem is: we are still in beta and there are still open issues with 64-bit plugins that have not been resolved. If we make changes to the plugin system during beta to make 64-bits work right and your add-on is broken, you won’t be able to react to it if it is already released.
So wait – make sure to test against the RC. Like new features and scenery file formats, while the new features is in beta, it is unstable and we’re not going to try to ‘protect’ you from change. Once we go final, things will be set in stone but we are not there yet.
(In beta 3 we changed our address space layout on Mac…that should give you an idea of how new this stuff is.)
X-Plane 10.20 beta 5 is out now – beta 4 was defective (installer-kitting problem). This build drops in a lot of new autogen.
The most immediate bug report I’ve gotten is third party scenery packs that are broken because they use library paths that are no longer available. I need to investigate what’s going on here, but I believe that we will need to post an updated library file that is not missing library definitions in a future beta. It may take a few betas to get this set up.
I also have not had time to attack most of the ‘meat and potato’ bugs that have been reported, so again it may take a few betas. We’re not rushing hard on the 10.20 run; I think it’s better to give third parties time to get their feet wet with 64 bits and make sure we address all of the technical concerns that come up from third party plugins.
About the New Autogen
The new autogen included in 10.20 beta 5 includes some of the new buildings that Alex has been working on; there is more that is not yet complete or published. The autogen art development actually consists of two tasks:
- Creating buildings and fragments of buildings (both mesh and texture) that look good and have high performance. Because we want to make the autogen fast, Alex tries to reuse sets of autogen where possible.
- Taking that “lego kit” of fragments and putting them into specific autogen art assets – autogen art assets are not just individual buildings – a single art asset builds an entire city block, encoding the rules for how a subset of the building fragments are used.
The main problem from 10.11 and earlier is that we had no autogen that provided urban buildings to irregularly shaped blocks – hence we fell back to the ranch houses, which just looked silly. The new drop has more irregular autogen with higher density urban buildings.
There is another chunk of autogen Alex is working on that is not done yet: buildings that respond to vertical information. This is why the Manhattan skyline just isn’t that “tall” – the DSF contains the height information. But while we have art assets that cover the shapes of the city without ranch houses, we don’t have enough art assets that can respond to the “tall” directive. When Alex drops that in we should see more vertical development.
I do not know what the timeline is for more autogen, but the general plan is simple: Alex will keep working on more art assets and we’ll periodically drop them in as we get them, each time bringing more realism to the existing global scenery.
Please file a bug if:
- You have no sound with the default aircraft in X-Plane 10.20 beta 3 (either 32 or 64 bit).
- You do have sound on 10.11.
- You are on Windows.
If you meet all 3 conditions, please file a new bug even if you filed this before; beta 3’s log.txt includes better diagnostics to try to trace this; we need to know if changes we made fixed this problem or if it’s still out there. (Like most configuration bugs, our machines here in the lab do have sound.)
Please do not file sound bugs against 3rd party aircraft in 64-bit mode; most of the time it’s the plugin not loading.
X-Plane 10.20 beta 3 is out. This build went out without new art assets. We have a pile of new art assets waiting to go out the door: autogen from Alex, more terrain textures from Albert, an airplane upgrade from Javier, and fixes to airplanes and aircraft from Tom.
But I held them back and kept them out of this release. Why am I such a bastard?
The answer is: two complex low level changes went into this beta, and I want to capture at least one beta’s worth of crash report data to check for destabilization. The new art assets may use more memory (especially if users crank them up to see what’s going on); if we rolled everything into one beta, we wouldn’t be able to tell art-induced crashes from code-change induced crashes. So we’ll roll things out in steps. As I have said before, the purpose of betas is not to have an awesome flying experience, it’s to find bugs!
Bear in mind that not all of the bugs reported are fixed; we cut beta 3 to get these two specific code changes fixed; more bug fixes are coming soon. Please see the release notes for what is fixed. please do not re-report bugs unless they are listed as fixed but still show up as broken on your machine.
I’m hoping to get a beta 4 out over the weekend with art assets if beta 3 goes smoothly.
So What Did You Do?
So what are the two bug fixes that are major enough to warrant their own beta?
- A change in the load order between X-Plane’s sound code and OpenAL. I realized that the old way we load sound (e.g. in 10.10) makes it virtually impossible for a globally installed plugin (one in Resources/plugins) to share OpenAL, even if it follows all of the rules set out in the OpenAL plugin tech-note. This change fixes that, apparently fixes conflicts between Gizmo and SASL, and hopefully should let plugins do the right thing. Plugin developers, see here for more info. (The original load order assumed that OpenAL would be more robust to two copies being opened; it now appears that this is not the case and OpenAL can be quite picky at times.)
- The OS X 64-bit memory layout has been modified to be compatible with LuaJIT 2.0, the Lua engine inside most Lua-based plugins (e.g. Gizmo, SASL, FlyLua, etc). This does not entirely fix the porting problems developers have been seeing with LuaJIT, but it at least makes the plugins work under light memory conditions. (These plugins would fail 100% of the time in beta 2.) Here’s the technote; I am in contact with most of the plugin developers using Lua, but if you use Lua and haven’t heard from me, email ben at x-plane dot com.
These are not the only bug fixes in beta 3, but they are the two that are weird enough that we want ‘clean’ bug data, without additional art assets to cloud our view.
So: hopefully these two changes will go smoothly and we’ll get on to beta 4 and art assets soon. The artists work their butts off to create this stuff and we want to roll it out!
Will Lua Ever Work With 64-Bit OS X?
A few developers who depend on SASL and Gizmo have asked me whether Lua will work with 64-bit X-Plane on OS X. The only answer that I can give is that I do not know, but I am optimistic that we will engineer a solution. I consider making Lua work to be a very high priority.
Lua is in almost every commercial third party airplane we’ve seen in the last few years; the market has spoken and third party developers have said “we like Lua.” So I think it’s worth doing some serious engineering to keep Lua working. Making Lua work with 64-bit OS X is currently my top priority bug.
As many have noted, QuickTime video recording is not available in the 64-bit version of X-Plane. This is not a bug; we will not be ‘porting’ QuickTime to 64 bits.
What we are going to do is:
- Maintain QuickTime capture in every place we have always had it: 32-bit Mac and 32-bit Windows.
- Someday we will transition from QuickTime to “something else” that will run on every platform, 32 and 64 bits. At that point we will drop QuickTime and have one universal capture solution. I don’t know what release this will be but it won’t be in 10.20.
My preference is for something that captures a fairly common and widespread format; photo-JPEG-compressed AVI is a candidate; remember the goal of video capture in X-Plane is not to make the best finished movies but to get the movies out with low overhead, for high-fps capture. That’s why we do QuickTime-JPEG and not MP4/H264, for example. Really good output formats like H264 require very long encode times to get their high quality high ratio compression. On the fly our goal with capture is just to get the frames out to disk for later processing.
Why No 64-Bit QuickTime?
The rest of this is just for programming nerds, feel free to let your eyes glaze over.
The problem is that QuickTime has two APIs:
- A 32-bit C API available on Mac and Windows (original “QuickTime”) – this is the original C API that dates back to Mac OS 8 or earlier.
- A 32/64-bit Objective C API (“QTKit”) available only on Mac (e.g. the only platform with ObjC).
We currently ship with that first API, hence no Linux support, and no 64-bit support – the API just isn’t available in those flavors.
I believe the work of porting to the new ObjC QTKit API would be about the same as implementing any other library-based capture solution, but it would only get us one OS in 64-bit. So when we do spend time to extend video capture, we’ll do it in way that works everywhere.
We’re not going to hold up 64-bit going final (10.20 final) for this; I think that there are more important features to move forward with: 64-bit, better rendering settings for autogen, DSF recuts, scenery tools. We’ll get to next-gen video capture, but we’re not going to try to jam it into this release.
Posted in News
by
Ben Supnik |
…a new operating system.
Here’s how I think about 32 vs. 64 bit: supporting both 32 and 64 bit ABIs in X-Plane is like supporting Mac and Windows. It means a little bit more work for programmers to cover more executable types but it lets users get more out of X-Plane and add-ons on a wider variety of hardware.
We’re not switch from 32 to 64-bit. We’re adding 64-bit native execution to our list of supported configurations. (Linux nerds have been asking us for this for years! 🙂
So I view the question of “when will my add-ons support 64-bit” as similar to “when will they support a different OS.” It will come with time, but no one is dropping the existing setup.
Developers don’t have the choice to pick 32 or 64 bits; the question is whether to extend support to 64 bits.
Did any plugin developers drop Windows support when they ported their plugins to Linux? I am guessing no. And I am guessing that 64-bits will be the same way.
This is already covered in the X-Plane 64-bit FAQ, but at a minimum we will maintain 32-bit support all the way through the v10 run. My guess is 32-bits will be around for the next major version too, but we’ll figure out those system requirements when the time comes.
BTW: beta 2 is out. Mac users, you have keyboards and mice again. (The bug only happened when you start the sim in full-screen mode.) Windows users, no spinning balls. And GeForce 200 users, your shaders compile. So at a minimum most of the face-palm bugs from beta 1 are fixed.
Posted in News
by
Ben Supnik |
X-Plane 10.20 Beta 1 is now public, and it is available in both 32 and 64-bits. First, here are some things you should read:
X-Plane 10.20 Beta 1 is a somewhat raw beta. Our goal is to get 64-bit executables into the hands of as many plugin developers as possible as early as possible. There are known bugs that we haven’t held the beta for. We have not yet shipped updates to the airplanes or new art assets for autogen.
At this point, this is the info we are looking for:
- Regressions: if something works in 10.11 but does not work in 10.20, please let us know ASAP.
- 32-vs-64-bit differences: if sim functionality does not work in 64-bits but does work in 32-bits please let us know.
- Plugin authors: do report problems with your plugins.
Here are three kinds of problems we do not want to hear about:
- Long-standing bugs in the sim. First, if you have already reported a bug, you don’t need to report it again. Second, we aren’t really ready for new bugs. If you report one, that’s fine, but we’re just going to file it until a later beta.
- Problems with someone else’s plugins. We really need to hear from the plugin author. Please don’t report plugin bugs on behalf of your add-on maker.
- Plugins that aren’t 64-bit ready. We do not need any bug reports telling us that a plugin isn’t 64-bit ready. This is normal and to be expected!
Finally, for users who are very excited about 64-bit: please be patient with your add-on makers. They are only getting a complete set of 64-bit build materials today. Please give them at least 10 minutes before hounding them for 64-bit updates.
Update: beta 1 has a bug on Mac where X-Plane will ignore keyboard input if it is started in full screen. If you have a mouse, you can toggle full screen off and on to get keyboard back. We’ll fix this for beta 2 shortly.
Posted in News
by
Ben Supnik |
