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.
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 |
Follow-ups to this post:
First, the Intel Graphics. There are two sets of chips in the bucket of 4th-gen Intel motherboard graphics:
- The older half of the bucket runs Open GL 2.0 only (with GLSL version 1.10). This chipset has never run X-Plane 10. Given how insanely old and underpowered machines with this chipset tend to be, given that the driver doesn’t even support GLSL 1.20, and given how many other problems I have had with Intel GPU drivers, I am going to declare this set of chips as “unsupported”, which I think is consistent with what we have told users with this chipset over time. I believe that no one has managed to make this chipset work on Windows, which is why no recent reports have been with this chipset.
- The newer half of this chipset runs OpenGL 2.1 and apparently runs X-Plane 10.05r1. I am trying to find hardware to test this bug, and I am trying to find a contact on the driver team, so we’ll see how that goes. This isn’t going to be quick to fix, because we don’t have the hardware in house. I strongly recommend against running X-Plane on these chips, but since it used to work, I’m going to try to fix whatever has gone wrong.
Second, joysticks: as far as I can tell, 100% of users with joystick instability are using game-port joysticks and not USB. So (this is getting to be a familiar refrain) I’m going to have to go find a gameport joystick to see if I can reproduce this problem, as all of my hardware is USB.
For gameport joysticks, we may be able to get some cases to work again, but some of what I have seen is way in the bucket of “unsupported.” Here’s a hint: if, to make your gameport work, you have to take OS components from an OS you do not run and copy them into the OS you do run so that you can trick a third party driver into installing, we’re not going to support that. If it works, great, but you’re on your own.
I am not going to hold up 10.20 beta for either of these issues; since they both involve finding hardware, there will probably be some delay in getting them fixed.
Posted in News
by
Ben Supnik |
A few foolishbrave 3rd party developers are testing 64-bit X-Plane builds, as well as our internal art team. Their early testing will help us fix a few of the “duh” bugs quickly before we go public beta, which should be Real Soon Now.™
(Please do not ask for a 64-bit build; we selected the first-round testers and we are not looking for any more private testers. Everyone will get the build soon!)
Posted in News
by
Ben Supnik |
Some of our users have the bad luck of having a laptop with Intel 4th generation graphics. This is the last generation of the “GMA” graphics cores – they generally come on motherboard (and often you’ll have one that you don’t use even if you have a PCIe graphics card) and they’re not very powerful. Motherboard graphics are designed to lower the cost of the entire computer for users who don’t need 3-d. They are not designed to make X-Plane look awesome.
These GPUs are causing two problems with X-Plane 10.10:
- They crash on startup when we ask the driver about our window’s format. Why it does that is not yet clear to me, but there may be a work-around.
- Our shaders won’t run on the GPU, which claims we ran out of texture units.
I consider this second problem very silly, as the card tells us how many texture units it has, the number is the same as every other GPU, and we don’t use more than those numbers. There may not be a work-around to the second problem; in particular if the shader compiler has a bug that causes it to misunderstand our shaders, we won’t be able to do anything.
So at this point X-Plane compatibility with the gen-4 Intel GPUs is an unknown. It looks like there are subtle core differences within the series that may also cause problems.
I can tell you this: if we ever get them running, it’s not going to be pretty or fast. I have the 6th generation GPUs (Intel HD graphics in an i5-2500) and the performance is not on the same planet as a discrete GPU.
Other Intel Cores
We do not support the 3rd generation and earlier GMA GPUs. The numbering scheme is really nutty, so that table can help.
We do support “Intel HD” graphics – they’re not great, but they do run. That includes any built-in mobo GPU from a “core i5” or “core i7” chip.
TL;DR
The short version is: if you have a gen-4 Intel GPU and see crashing, please stand by; we are investigating now. We will either fix the crash and provide a work-around in the upcoming 10.20 patch or declare the GPU unusable. I’ll post an update in a few days.
Posted in News
by
Ben Supnik |
X-Plane 10.11 is now final, so you will receive an update notification even if you have not participated in the beta program.
Starting with 10.11, I am stripping the ‘r’ designation off the end of the build; the complete build number is still visible in the log file and properties, but what you see on your startup screen will just read 10.11.
I do not know if we will cut an X-Plane 10.12 before we get into a 10.20 public beta of 64-bit; I have seen a number of bug reports for 10.10/10.11 that need investigation, but I don’t know if the problems are due to bugs, running out of memory, rendering settings cranked too high, etc.
The main goal of 10.20 is to get us to 64 bit; we’ll also ship better anti-aliasing and autogen in that build. We aren’t sure what will come in 10.30, but at this point more performance tuning and stabilization is likely.
A while ago, I wrote up a summary of the issues with OSM and water. I still do not know a time-frame or plan for OSM recutting, but I can say it will be after getting 64-bit done, and once 64-bit is done, it will be high priority. If the water you care about is not in the OSM map itself, a recut won’t help until you or someone else in the OSM community updates the map.
(For Americans who are frustrated about water that was in X-Plane 9 but is not in X-Plane 10: X-Plane 9 used US Government data. There is work in the US mapping community to get the NHD data into OSM; I suggest participating in this effort. You can import and check a single water shed and thus bring a local region up to date, and the changes are ‘forever’ since they are in the OSM data set themselves.)
X-Plane 10.11 rc3 is ready for testing. If you see a lot of spurious warnings about LOD errors in your Log.txt file on Windows, get this build by running the updater and checking “get betas” – it should help.
Posted in News
by
Ben Supnik |
