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 |
I’m trying to migrate our developer documentation from the Wiki to this site. See the menu up top for articles, file formats, and tools.
One document I just posted here: A Checklist for Updating Aircraft to X-Plane 10. If you are working on airplane conversion, I strongly recommend looking over the various items. A lot are “check that X isn’t hosed” – there are very few mandatory changes.
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 |
This post follows up on the case for DDS and DDS in v10 and answers some basic questions.
DDS and Texture Compression are Not the Same!
This is the first and most important point: the decision to compress textures and the decision to use DDS are not the same!
Texture compression is decided by the user. If the user clicks “compress textures” (and nearly all users should do this) then 99% of the textures in your add-onwill be compressed. You can’t avoid this. The user has spoken and said “sorry, I don’t have 3 GB of VRAM, we need to tighten things up.”
DDS is a pre-compressed format; DDS says “well, if you are going to compress, I have already done the compression for you with DDSTool, so it will look better. See the pictures in the posts above for why this is so important!
I cannot emphasize this enough: most users are going to have to use compression to save VRAM, so you should ship DDS files so that the compressed images look good. You can ship DDS and PNG if you want to ensure that the uncompressed case looks good too, but I think that users running uncompressed is going to be rare.
Does DDS Improve Framerate?
No! See the above post: the user may be running compressed textures regardless of whether you ship a DDS, so when you ship a DDS you may see no VRAM savings and no FPS change. All you will get are compressed textures that look better.
Does Compression Improve Framerate?
Sometimes. Texture compression will improve framerate under two conditions:
- The texture unit bandwidth on the GPU is exhausted. This is very rare now – I haven’t seen this happen since the Radeon 9600 XT.
- The user is out of VRAM. This is quite common.
But recall how free VRAM affects framerate:
- When the user runs out of VRAM, the fps loss is often catastrophic. The user might see huge jerking, big pauses in framerate especially as the camera moves, and performance will be unusable.
- When the user has extra unused VRAM, there is no benefit – framerate does not go up indefinitely by freeing up VRAM.
So most users will simply turn down texture resolution until they can fly. Thus the real effect of texture compression is to let users turn their overall texture resolution back up again one notch, improving the overall look of the sim.
Is There Any Way to Make DDS Look Less Bad?
Sometimes DDS is relatively harmless to a texture, and sometimes it just absolutely destroys it. I don’t have a good answer to this, except: be sure to run the latest DDSTool/XGrinder (see the “command line tools” option on this site) when targeting X-Plane 10, and never set your gamma to anything other than 2.2. I do hope to someday look at improving DDS grinding capabilities.
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.)
