X-Plane 10.20 beta 9 is out and (hopefully) fixes missing library paths. Alex and I spent a good chunk of yesterday trying to clean up the tools that generate the autogen library, but it is a very complicated problem, as indicated by the 4786 distinct entries in the library.
Beta 8 and 9 introduce a change in how the rendering settings work; my suspicion is that users seeing a framerate drop in the new betas are seeing the effects of the intermediate rendering settings acting differently; the minimum and maximum for the settings should produce nearly identical results.
I’m not going to try to explain how the settings used to work – the actual results were extremely convoluted due to quirks in the engine. This change is one of several we want to make to both improve how the settings work (from a usability standpoint) and improve the look of the autogen at lower settings.
- The “objects” popup controls the amount of autogen and 3-d stuff in general. Besides adding more autogen, it adds more detail to the autogen as it appears and can even add more detail to custom scenery. (This behavior isn’t new.) In particular, if you use an a complex library element like an “AGP” scene (e.g. the control tower or FAA building) the amount of detail of that mini-scene will increase with the objects setting. The goal here is to have the objects slider control the amount of 3-d.
- The “forests” popup now strictly controls the density of all vegetation in the sim. This includes both the natural forests (.for files for DSF nerds) and the vegetation that is part of the autogen (e.g. the trees that Alex puts down on the lawns of houses). Lower forest settings tend to prioritize the rural forests over autogen trees to save framerate.
- The distance to which 3-d is drawn is controlled by “world detail distance” – this is how far anything 3-d is drawn out to. Finally with this change, this affects the forests as well as the autogen and the roads – everything runs to the same distance.
A few tuning tips:
- If you are running 32-bits, turn “world detail distance” down by at least one notch; having a shorter distance for 3-d will allow the sim to save some memory.
- If you run with full autogen, moderate forests, and highest world detail distance, you may now need to turn forests up and world detail distance down to create the equivalent of what you used to see. In older betas, the forest setting modified world detail distance in some very strange ways.
Our eventual goal is to keep the autogen base footprints even when the object count is very low; the footprints of the autogen contain views of the building tops, allowing for the equivalent of ‘orthophotos only’ for users with very low rendering capabilities. This will help avoid the ‘sea of green’ effect on lower settings. (The behavior now, where whole city blocks disappear) will eventually go away, to be replaced by the “footprint” with roofs of the city block when 3-d is turned down.
These pictures illustrate the effect of world detail distance. Note that the ground images attached to the buildings are still present even as the buildings begin to disappear with lower settings. The last picture shows the autogen with most 3-d buildings stripped away to reveal the ground tiles underneath.
As we keep working on the autogen system we’ll get more and better ground textures in place, more and better ground tiles on the autogen, and yet more buildings; the result should be a reasonably seamless urban experience at a range of rendering settings.
Some cities are “over-green” in their underlying data in the DSF – this happens when the source land class is difficult to ‘fit’ into the grid system efficiently. (Typically a little bit of vegetation or water area affects zoning and ‘greenifies’ a large area.) We will have to address this problem in DSF tile recuts. (In other words, zoning errors are a failure of accuracy compared to the source data, to be recut; adding more autogen improves plausibility by providing a wider variety of “stuff”.)
Edit: Beta 8 isn’t particularly live; the autogen library is screwed up again (by me). I’m fixing it now and will then recut the beta. I’m looking at what I can do to improve the library generation process – it’s a series of scripts, and as you might guess from the number of times it’s gone sideways in 10.20, it’s held together by shoe strings.
X-Plane 10.20 Beta 8 is now live. This beta does not contain all of the bug fixes I wanted to get into the next beta. But we had to change the networking protocol between X-Plane and Xavion, so this beta is timed to app-store approval.
With that in mind, there are some key bug fixes: hopefully the facade engine is back to sanity (if not, please re-report facade bugs) and I finally found the cause of incorrect fog on the horizon in 2x SSAA mode.
Here’s the main point though: there are still plugin system changes coming for 64-bit that are not yet in this beta. Please be prepared to test your 64-bit plugins against a future beta; do not assume that your plugin is ready to go just because it works now!
Please read the requirements below twice – this is a very particular setup I need. To run this test you must have either:
- A functioning hackintosh running the latest Mountain Lion release (OS X 10.8.x) or a functioning Mac Pro running the latest Mountain Lion release (OS X 10.8.x) and
- An NVidia 560,57,580 or 660,670, or 680 desktop GPU in that machine and
- The computer must also be set up to run of Windows Vista or Windows 7 in Bootcamp and
- You have or are willing to run the 10.20 beta (at least as a demo and)
- You can run command-line fps tests if given instructions.
Please do not reply to this if you do not meet all three hardware requirements; I am looking for someone who can do a clean apples-to-apples comparison of NVidia driver performance between Mac and Windows.
Please do not comment on the post if you do not meet these requirements; I am going to clip the comments pretty tightly on this one.
EDIT: thanks, but a user already sent me the test data I needed!
I hate to put time estimates on anything. The reason: timing is subject to change and always has a ton of uncertainty. What we internally is not a schedule. A railway has a schedule; we have a plan, a roadmap, or some goals. Betas are full of uncertainty. We don’t know what bugs are in the sim – if we did, beta would be over a lot faster.
So: this is my current thinking on the timing of the rest of the 10.20 beta, as of now. It will be obsolete within five minutes. Since most of the time schedules get screwed up by things being late (if we were ahead of schedule we could just choose to not release to be on schedule 🙂 this is post may be useful for third party developers trying to plan releases.
If things go well, I believe we will be able to build a 10.20 release candidate this year. (That’s a tighter goal than it sounds – there are only two weeks left.) I think we will not finalize that release candidate this year; more likely we’ll sit on the release candidate into a little bit of January. The release candidate will hopefully be settled enough that there are not any engineering surprises for third parties if we have to recut the release candidate.
If things go badly, we won’t be RC this year – there’s always the chance that someone could have a sick kid, a power outage, new bugs could be found, you name it. Life is full of uncertainty!
I do not know what autogen will get dropped into the beta or when. If we have autogen that is almost ready for 10.20 but misses the release deadline, we’ll drop new art assets into a 10.21 or 10.22 – it’s very easy for us to do a bug fix patch with more “stuff” in it.
If I was gambling, I’d bet that there will be a 10.21 anyway – what we found with 10.10 is that a lot of users didn’t participate in the beta, and thus we got a flood of bug reports right after 10.10 went final. This can be frustrating for us (in that it means that our beta coverage isn’t as good as we’d like in terms of hardware configurations) but it’s also good in that it means that the entire community isn’t in on the beta (something we don’t want – we don’t want to expose every X-Plane user to beta bugs!).
Edit: Normally I label the overly technical posts as being for a target audience, but I did not this time. My bad — this post is really only of interest (and will only make sense) to serious 3-d modelers – the advanced airplane and scenery nerds!
The brightness of specular hilights is out of sync between HDR and non-HDR mode in X-Plane 10.11. This wasn’t intentional – it’s a bug. 10.20 will fix this; specualr hilights will have the brightness you see in non-HDR mode (which we think is more like they were supposed to work*) but the tinting of HDR mode (non-HDR mode was overly red in 10.11).
I get a lot of requests for ‘hardness’ control – that is, the exponent that controls how wide a specular hilight is. We’ll get this feature eventually – it’s too important to ignore. The main delay in having this feature is that X-Plane uses a deferred renderer, so the specular exponent has to be stored in the G-Buffer somewhere, and storage is tight.
For similar reasons, it is very very unlikely that we’ll ever have RGB tinting of specular hilights. Doing so is 3x as expensive in G-Buffer storage, and we need that storage for other features.
* That is, unless we discover that non-HDR mode looks spectacularly bad in some cases, in which case we may have to push things a little more toward how HDR was.
There is one particular library problem I see all of the time:
- Scenery pack A exports a pile of art assets to the library.
- Scenery pack B uses them.
- User X installs scenery pack B but not A, and can’t run X-Plane.
X-Plane provides a way to work around this: a library pack can contain an EXPORT_BACKUP directive that tells X-Plane “use this art asset if you can’t find it anywhere else” – it’s for place-holder art of last resort.
So scenery pack Bcould contain a library.txt with the backup art to allow it to function (badly) without scenery pack A.
But, even though OpenSceneryX provides this “backup” library, I see over and over again scenery packs with no backup, and confused users who don’t understand why their sim doesn’t work.
I am open to ideas on how to fix this.* One idea I had (which may or may not be useful): allow scenery pack B to list in its library.txt the scenery packs it requires by some human-readable name.
Then if/when X-Plane can’t find library files, it can provide a useful message like:
The scenery pack “Awesome Downtown NY” could not be loaded because you have not installed the scenery pack “OpenSceneryX.” Download and install “OpenSceneryX”, then restart X-Plane.
But I am skeptical: given the low adoption rate of EXPORT_BACKUP I am not sure that authors of scenery are paying a lot of attention to library dependencies.
* But not this idea: just load the pack without art assets. I strongly believe that if X-Plane allows broken data to load, the amount of broken data in the scenery packs out there will go way up. We have seen this happen over and over again; the quality of third party data is proportional to the severity of error checking.
Beta 7 is now out – see the links to the right for release notes and bug reporting. Beta 7 fixes a few fire drills with beta 6. Good times!
Plugin Developers: you have to link against the libraries you use. You cannot depend on X-Plane to provide those libraries for you!
Historically, due to poorly chosen project settings in X-Plane, X-Plane would “leak” libpng, libfreetype, and (in 10.10) libcurl. Plugins that used these libraries without properly linking against them would still function: X-Plane would accidentally export these libraries, hiding the fact that the plugins accidentally didn’t link against them, and two wrongs made a right-for-now-until-something-changes.
If your plugin won’t run with X-Plane 10 beta 7 (32-bit or 64-bit), it means you’re not linking properly. The 64-bit build in particular does not share any static libraries. So whatever library you need, go find the .a or .so or .dylib or .dll or .lib and link against it! If you are on Unix or Mac, you can type
nm mac.xpl | grep "U "
To see a list of undefined symbols. You should only see libpng in there if you linked against libpng.dylib or libpng.so. If you are trying to link statically to your support libraries (and this is definitely the path I recommend) the only “U ” symbols you should see are XPLM and XPWidgets routines.
I will try to post additional SDK documentation on linker settings this week!
Update: this crash may only be happening to users who have ‘runway follows contours’ off. I still don’t ever see this on my machines, even when I do what I think should cause the bug based on the code and crash reports, but we’ll get this fixed somehow.
To hack around this, open X-Plane.prf in your favorite text editor, find the line that says
renopt_sloped_runways 0
and change the 0 to 1. You might be (temporarily) back in business with beta 6.
Ever wonder where your crash reports go? Let me show you!
That’s a screenshot from the back-end tool we use to look at crash reports – in this case, it is a view of all crash reports submitted against 10.20 beta 6 on all platforms, sorted by how they crashed. Clicking on the links drills down for more details, but in this case, the one picture says it all: the code to “inflate” airports (that’s the code that turns an apt.dat file into real 3-d triangles) is crashing.
As far as I can tell, it’s bad luck that this crash happens at some airports but not the ones that I visited during testing; anyway, beta 7 “real soon” – realistically it’ll be 24 hours before I can get another beta posted.
It’s always a good idea to auto-report crashes – we don’t have to worry about “too many reports” because, as you can see, the reporting software gets us a very nice, clear picture of what’s going on.
Anyway, I’m sorry about the delay – we’ll get this fixed and then regular testing can resume.
10.20 Beta 6 is out – this build fixes the missing paths in the library that were causing the dreaded “Could not load fac/forest/beach” error. This build also puts in some important changes to 64-bit plugis, so below I will try to point out what matters to select audiences:
Users:
If you don’t make an add-on but you are still testing 10.20, there is still a kind of testing that we need (but you may not like it): is anything broken in the 32-bit edition of 10.20 that worked in 10.11?
This kind of bug (it worked in the old version but is broken now) is called a regression bug in the tech lingo, because the sim has “regressed” – it has gone backward. This is the most important kind of bug for us to find for three reasons:
- No one wants to go backward.
- It’s easier for us to find the bugs in new features than random bugs in features we didn’t think we had changed.
- If you report a regression bug against two versions of the sim (it worked in 10.11, broken in 10.20) we have tools to see only the code changes from 10.11 to 10.20, which makes finding the bug much quicker.
So: please try the 32-bit 10.20 and if it fails at something that 10.11 did, please let us know ASAP!
Aircraft Developers
This build fixes the prop disc and airspeed indicator, and finally provides more datarefs for the anti-ice system; I suggest rechecking your airplane with these systems. At this point I think I only have two airplane issues floating around on my radar:
- The new light billboards and spill can be tricky to use, particularly when lights crash through the fuselage of an airplane.
- The manifold pressure indication is FUBAR on helicopters.
Both of these bugs were present in 10.11.
In fact, we have no regression bugs on file in the airplane system between 10.11 and 10.20 32-bit. So if you know of something broken with your airplane that is newly broken in 10.20 32-bit, please report it ASAP. (You do not need to re-report bugs that were already present in 10.11 like the manifold pressure.)
Plugin Authors
This build integrates a fix for LuaJIT on 64-bit Macs; see the release notes and plugin SDK for how to use it.
This build also strips out the symbols of libpng, libcurl, and libfreetype2 on Mac and Linux. These symbols never should have been visible in X-Plane, but they have been for years.
- If your 32-bit plugin used to work on X-Plane 10.11 but stops working on 10.20 32-bit beta 6, please file a bug and we will figure out what to do.
- If your 64-bit plugin use to work on 10.20 beta 5 but stops working on beta 6, your makefile or X-Code settings have a bug; post to the x-plane-dev mailing list to get help.
There may be future changes to 64-bit like this one; this is why I recommend not releasing while we are in beta! Our goal is to ‘get 64 bit right’ now during beta while we can try and test.
Scenery
There are no open regression bugs from 10.11 against scenery; facade textures were borked and are now fixed, and the library should be restored. So if your scenery pack worked in 10.11 and fails in 10.20, please report this ASAP!
I do have one open bug (present in all of the v10 run) that line markings are losing line segments; I hope to get that fixed by the end of beta.
(We also have a report that certain incorrect ATC/apt.dat files will hard-crash the sim – I think Chris will probably be able to get some better validation in place before beta ends.)
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.
