See here for release notes with a list of bug fixes, and file bugs here. (BTW, if you are going to email one of us to ask if you should file a bug, please just file a bug. 🙂 It’s quicker for us that way and for you too!)
If you already have 10.10 beta 1, simply launch it – the auto-update will kick off much earlier during load. If you don’t have beta 1, you need to run the DVD installer or demo installer and update with “Get new betas” checked.
And if you would be even remotely sad if your computer sprouted legs, stood up, grabbed your USB joystick and threw it out the window, don’t install betas. Everyone will get 10.10 once it is final – install the beta only for testing purposes, not for flying enjoyment!
Posted in News
by
Ben Supnik |
Just a few quick notes on the 10.10 beta process…
First, we have received well over 1000 automatic crash reports. For those who have not figured it out from reading forum posts, 10.10b1 crashes on startup with some combinations of joystick hardware and its associated software. Chris has a fix for this which will ship in beta 2, some time this weekend.
Thank you to everyone who has clicked “send to Laminar”. Receiving such comprehensive and complete crash data is really really helpful. We get a very clear picture of what’s happening with complete details. Clicking “send to Laminar” is better for us than filing a bug (because the crash reporter is very thorough in grabbing forensic crash data and the crash submission system pre-processes the crash for us, saving us labor) and hopefully it’s easier for you too.
Also, thank you to everyone who has filed bugs on the bug report form! We really do read every one of them, even though we do not reply to all of them. We try to list fixes in the release notes so you can see what’s going on.
Overall behavior re: posting bug reports on the comments section has been quite good, but I will continue to trash bug reports here. I apologize for the inconvenience, but my fear is that if I start responding to bug reports here, it will encourage other users to “file” bug reports on the blog too and then we’ll have a mess on our hands.
To be clear: my goal is not to snuff out negative feedback. This is not “if you have nothing nice to say”. But…most negative feedback really should be a bug report, e.g. “X used to work and now it is broken” really belongs on the bug report form.
I am fixing my last bug for beta 2, which I hope to have cut over the weekend.
***CHRIS’S EDIT*** We’re aware that having a joystick plugged in destroys frame rate…That’s already fixed and will also be in Beta 2.
After a last-minute morning recut (previous beta candidate was missing 80% of autogen, which is actually a great performance enhancement 😉 10.10 beta 1 is available for download to the brave and foolish. Some notes:
- No bug reports on the blog. Bug reports go here! Please, no back-door bug reports via “is X still broken”? When it’s fixed, we’ll release note it.
- Speaking of which, release notes here!
- As long as those notes are, it still doesn’t do justice to how much changed. For example, we spent a lot of time making things 64 bit safe, but since that’s not done, no release note. I had 215 commits to go through for 10.10 – not sure how many everyone else had.
- I’ll try to get docs up (and updated) on some of the new scenery features; further improvements to the rendering engine have put me even farther behind. But a lot of the rendering engine improvements are either for Alex’s use in autogen or just make the existing stuff work better.
- One thing you can tell from the 10.10 notes is that we’ve put a tremendous amount of emphasis on usability; when we looked at 10.00r1 after shipping, we identified a number of areas where using the sim (especially as a new user) just wasn’t fun, easy or welcoming. The new features in 10.10 include those plans coming to fruition, finally.
To get the beta, run the X-Plane installer/updater or demo installer, pick “update” and check “get new betas”. X-Plane will not prompt you to automatically update your stable 10.05r1 into the unstable 10.10 beta 1.
Finally, X-Plane 10.10 beta 1 is the first beta after a huge amount of code change. If you like to fly X-Plane for fun, do not update your “working” X-Plane install to 10.10; it’s too new and too raw. You can copy your X-System folder (or part of it) and then update the copy.
[Hint: now that we have sym-linked scenery, you can copy your folder minus custom and then sym link custom scenery back into place. Sym-linking is not supported for airplanes and global scenery.]
Posted in News
by
Ben Supnik |
Here’s another thing that’s new in 10.10: safe mode on startup.
One of the most common sources of tech support is users who can’t start X-Plane because their previous rendering settings crash the sim when restarted. This often happens from maxing out system VRAM or process address space, but it can also happen due to driver incompatibility. The problem that hoses users is that the setting change takes effect on restart, causing a “lock-out” condition.
X-Plane 10.10 knows if it shut down cleanly or crashed; if upon start, it realizes that it crashed, it will offer to run with default rendering settings. This makes it easy to restart an rebuild rendering settings without losing all preferences.
This is not a replacement for improvements in rendering engine stability and 64-bit but it should help for now and will always help for edge cases where a particular hardware combination crashes in a way we’ve never seen.
X-Plane 10.10 is compiling now; in theory it should be up tomorrow morning. Obviously if the build crashes on us before it is uploaded we’ll recut it.
In my tentative list of features from this blog a while ago I forgot to mention that 10.10 has some of the scenery management features I mentioned a few months back during the dev conference in Columbia: scenery packs can be reprioritized or disabled by a text .ini file and they can be on other hard drives.*
To be blunt, I think beta 1 is a little bit gooey and underdone in the center. I think there will be a big difference in quality between the first beta and what we have 1 week later. The main bugs we are interested in early on are regressions, e.g. things that worked in 10.05r1 but do not work in 10.10b1, especially with third party add-ons.
Two notes on bug reporting:
- You do not need to re-report bugs that are not listed as fixed in the release notes. We try to post long, detailed release notes so that you don’t have to waste your own time repeating bug reports. If it isn’t listed, it means we haven’t gotten to the fix yet. Beta 1 does not fix all bugs we know about!
- Please do not post any bug reports on this blog. Please do not post bug reports on this blog even if you have also filed a bug report. Please only file a bug report on the bug report form.
I am going to be a complete bastard about that second point. If you post a bug report as a comment, I will delete it without reading it. If you do this multiple times, I will ban you. We really need all bug reports to go to a single place. When they go to the bug report form:
- One person initially reads all of the bug reports. That means that duplicate bugs are rapidly recognized as dupes, wasting less triage time and helping us understand what bugs occur frequently (so we can fix them first). When bugs go into multiple places then more than one engineer looks at them and a lot of effort gets wasted.
- With the bug report form, we control who it goes to. We can change who reads them if someone is out of the office or overloaded.
So: no bugs in the comments section – it’s the best way for all of us to get to a stable, final 10.10 faster. I will post links to release notes and the bug report form when the beta goes live.
* Unix nerds: yes, ln -s works on Unix OSes. The feature here is that aliases and shortcuts made using the Finder/Explorer by non-geeks work too!
Posted in News
by
Ben Supnik |
While working on the HDR pipeline, I ended up with these. Clearly not what we want to ship, but I do think they’re pretty cool looking.
At this point the only thing holding up a public beta of 10.10 is, well, me. I am currently working on a set of related aircraft rendering bugs, and as soon as I can get the car off of jacks, we can go beta.
One of my goals or 10.10 is to close out the issues that stop payware authors from releasing final conversions of their aircraft to 10.10. By final, I mean conversions that won’t need any additional future editing. Right now X-Plane 10.05r1 has a few bugs that cause v10 to look different from v9, different depending on rendering settings, or just wrong. I want to fix those problems in a permanent manner so that authors can release aircraft and not worry about having to update.
Here are my goals for 10.10, roughly in priority order:
- Rendering should be consistent from X-Plane 10.10 onward through the rest of the v10 version run.
- Rendering should be consistent between HDR and non-HDR mode. Authors should not have to create two versions of textures where the HDR and non-HDRs offer the same capabilities. (In other words, while you might have to make two textures to bake lights when in non-HDR mode, you shouldn’t have to make two textures to correct for differences in color-correction between the two renderers.)
- Where possible, non-HDR mode should match X-Plane 9.
The switch of priority between item 2 and 3 is a fundamental change in priority from what I originally intended for X-Plane 10.
Originally I thought that the best thing to do would be to keep non-HDR rendering as close to v9 as possible, so that at least content would look correct with HDR off.
My new thinking for 10.10 is that we should aim for consistency between HDR and non-HDR modes. Realistically, an author is going to have to make at least a few adjustments in moving v9 content to v10; better to have the cost of rendering engine changes be borne out in a v9->v10 upgrade than to have every v10 airplane require double authoring to cope with HDR vs. non-HDR differences. In the long term, it’s best to not have v9 haunt v10 like a ghost years after authors are making exclusive v10 content.
Why is HDR Mode So Weird
This begs the question: why is HDR rendering so weird? Why does it look different from non-HDR rendering, and why doesn’t it look the same as v9? What did you guys do?
There are a number of changes to how we render in X-Plane 10, some specific to HDR rendering, and some sim-wide.
- The entire sim now works with a linear lighting equation. Basically when the sim performs lighting calculations on the GPU, it thinks in terms of photons and not colors, which produces more realistic results in most cases. With lots of light sources, linear lighting is absolutely necessary for combining those lights.
- The order of rendering operations is very different between HDR and non-HDR mode, and the formats that they render into (24-bit RGB vs. floating point, etc.) are very different. HDR is fundamentally a two-pass format.
X-Plane maintains two separate rendering paths for HDR vs. non-HDR and they are quite different in both what happens at each stage and when the stages occur.
Fixing some of the authoring bugs has required further changing the HDR pipeline to allow for correct rendering. The up-side of this change in pipeline is that the new one supports better HDR tone mapping and possibly even better fill rate performance. The down-side is that it’s a lot of complex code to touch and it may take a few betas to work out the bugs.
So I just realized that it’s been a full month since I’ve posted anything on the dev blog, which is a bit ridiculous since we’re working on a ton of stuff for 10.10 and a number of announcements have also come out in the computer industry. I’ll try to catch up on various topics over the next week.
Where Is 10.10???
I’m pretty sure that that’s the money question: where is 10.10? The answer is: we are working on it, mainly fixing bugs pre-beta. When will the public beta program start? I don’t know – that will be determined by how quickly we can knock out some of the current bugs. My view is that it’s a waste of everyone’s time to go beta on 10.10 with known bugs that we can fix without going beta – going beta too soon means users waste their own time reporting bugs we know about, and we are distracted from fixing those bugs with the task of going through the duplicate reports.
64 Bit – Not Yet!
I think we’ve described this road map before, but in case there is any confusion let me be absolutely clear:
X-Plane 10.10 will not be 64 bit!
We have already made significant progress toward a 64-bit X-Plane and we will continue working on this front. But the plan was never to ship 10.10 with 64 bit support. Rather, X-Plane 10.10 ships with a number of changes to our compilers (as well as a ton of other stuff). The next major patch (10.20) will support 64 bit on all three platforms at once, and we will know that any problems will be due to the 64-bit-ness (and not the changes to compiler, runtime, makefiles etc.) because those will have been vetted in 10.10.
The reason to ship 10.10 in 32-bit is to get out all of the other changes we’ve made so far.
What’s In 10.10
This is not a complete feature list – when we do the first public beta we’ll run through our source control log to scrape out all changes. But here are some fairly big things:
- Austin is putting new UI into the sim for flight setup and airplane selection.
- Roads don’t shoot up in the sky anymore – crazy road grids was always a problem in how X-Plane showed the data, not the data itself. This change may also improve the stability of the sim.
- Chris has integrated “breakpad“, an open source automatic crash reporting system. The vast majority of the bug reports we receive are crash reports, and of them, the vast majority are missing critical files we need to understand what crashed. Automatic crash reporting should both save users time in reporting (you just have to click “ok” when X-Plane asks you if you want to send the bug to LR) and let us dig in with complete file information.
- 10.10 includes faster clouds on ATI hardware on Windows.
- This build moves us to new compiler setup – while this is an internal change, it should mean faster load times on Windows.
- 10.10 fixes some stability problems in 10.05r1. I don’t think the early betas will be great for long flights, but I think 10.10 will in total be better on this front. (But note: a lot of the crash reports we get are due to running out of memory. You can’t run X-Plane at the edge of your memory limits for 10 hours of flight – at some point it will go over. This particularly applies to Mac users.)
- Chris has rewritten the low level joystick code; while this was suppose to be ‘just the hardware’ code (with new UI coming in 10.20) it looks like one aspect will go live in 10.10: you can plug and unplug your joysticks while you fly without restarting the sim.
The artists have been working this entire time and we’ve built up a pretty good pile of art assets to ship too – I’m not going to try to enumerate them right now because I’m not up to date on what they’ve created.
Third Party Airplanes
One goal I have for 10.10 is to close out all of the bugs that are stopping authors from converting their payware add-on planes from X-Plane 9 to 10. Some of these are already fixed and some are still on my todo list. I’ll post more about some of the stickier remaining issues in another post.
This post will pretty much only be of interest to Linux users – everyone else, talk amongst yourselves. Topic of discussion: X-Plane.com is neither a plane nor a communist. (Sorry, work on the road processing code has drained me of any remaining sanity.)
Linux History
The brief history of X-Plane for Linux is that Joshua Wise ported X-Plane to Linux a while ago because he felt like it (and being too young to drive at the time, apparently had some free time). The Linux port was never a commercial effort. – Laminar Research didn’t say “we’ll make a ton of money by porting to Linux, so let’s hire someone”. It just sort of happened. (Well, I wasn’t in the room so I don’t know exactly what was said.)
Linux has steadily represented about 5% of our user base from that point on, and this gets to the “commercial problem” of Linux: even with the work we do to try to keep platform specific code in X-Plane to a minimum, Linux sales don’t justify the development cost to maintain the platform.
Yet there still is a Linux version of X-Plane. We keep renewing the Linux port for “one more version” because while the Linux community doesn’t buy a ton of copies of X-Plane, Linux users do contribute in an outsized way by providing code back to the scenery tools and other development efforts. In other words, the Linux community doesn’t contribute dollars, but they contribute a lot of code.
Code Contributions
This came up during the X-Plane 9 and 10 Linux discussions. Our primary request to Linux users has been “please support each other”. There are too many Linux distributions for us to provide support; our dedicated support staff does not even have Linux expertise, so Linux support immediately hits engineering.
While a number of Linux users have really done a great job of helping other users out, another issue came up. One of the ways we try to minimize Linux-specific costs is to keep the OS-specific code very basic and rudimentary. In the past we’ve taken patches from users to fix OS specific bugs, but this is an awkward process at best.
Some Linux users asked if we could find a way to release source to the OS-specific parts of X-Plane so that they could improve the Linux-specific code (and thus the platform-specific experience) themselves. Right now this is a very awkward process: I have to tell the user “give me a snippet that does X” and then hope that I can get the snippet integrated and tested on my own.
One of the suggestions that came up at the time was to separate out some of the code that abstracts the OS/hardware so that Linux users could patch it more easily.
A Hard Abstraction
Separating out the platform specific code is a good idea, but it wasn’t one we were going to drop everything to pursue – if we did, the end result would be no improvement to X-Plane after some number of weeks of heavy development. Instead, we are slowly moving the code in this direction as we work on it.
The first code to get a work-over is the joystick code; Chris has been refactoring the joystick code for a few weeks now. 10.10 won’t show you any new behavior; it runs the existing UI on top of new low level code. Once we are sure this works, Chris can implement a bunch of new joystick UI features on top of the new low level code quite easily.
The new joystick code separates out the OS-specific joystick interface code from the rest of X-Plane. In the long term, this will make it practical for us to share the hardware abstraction code with users as source, take patches, and even allow developers to swap it out on their local development machines via a shared object. We’re not there yet with this level of flexibility, but the new code makes these things possible.
You Can Keep Your Hat On
There is one immediate win to the new code that will be apparent to Linux users in X-Plane 10.10: the new code (which is based on input.h instead of joystick.h) recognizes hat switches as a set of buttons, rather than a pair of axes; this is almost certainly better from a UI configuration standpoint.
I fear one of the main points of my last post was perhaps lost in the excited discussion of how to cope with conflicting crowd-sourced airport submissions. The engineering principle is:
Fix real bugs, not hypothetical bugs. Solve real problems, not hypothetical problems.
By this I mean: it’s invaluable to wait until you actually have evidence of a problem before you design the solution. Without a real data point showing what the bug is, the solution might not actually fit the problem as it actually happens. In a program as complex as X-Plane, particularly when third party content is thrown in, it’s hard to predict in advance what is going to go wrong.
In the previous case (coping with conflicts) the key here is that I want to see a few conflicts before I choose a plan. I see proposals for a revision system, public logs, a registery, a voting system…any one of these ideas might be the right solution, but we don’t know yet because we don’t have two people submitting buildings.
The same principle applies to another issue that was brought up a while ago:
Won’t all of the default airports look the same since they all use the same library?
First, to be clear: we’re not trying to make the default library airports look like the real world airports, we’re not trying to duplicate custom scenery, and if people submit buildings for all 20,000 airports in X-Plane there’s no way we’re going to have 20,000 control tower libraries in the library.
But there is a valid issue: what if people heavily use the assets? Won’t we start to get a “sameness” either between two airports or within an airport as we use the library more and more?
This brings up the second half of “fix real bugs”:
Identify possible solutions, but don’t use them until necessary.
I am not worried about collisions of airport because there are a huge number of possible solutions, many of which are easy to implement and have been proven to work well in the real world in other problems. In other words, the problem of merging crowd-sourced data is a solved problem, and we can use the right existing solution when we have enough data to pick that solution.
The same thing applies to repetition in the library: we have ways of fixing repetition. I want to develop a few airports and see what looks repetitive before asking our artists to spend their time making more stuff* but we at least know how we can fix the problem when the time comes.
Options to Deal With Repetition
So what are the safety valves here? How can we deal with repetition in the library? There are a few ways:
- Every object in the library can have multiple real OBJ models for each “virtual” object. X-Plane picks randomly among the choices, so we can always add more real objects. We already do this for cars. (There are something like a dozen cars and trucks backing up one or two library entities.)
- Some of the library elements are .agp (autogen-point) files – these files are mini-scenes made up of other objects, and the objects referred to within the scene are also subject to library variation. So we can have a mini-scene where some of the decorations are constantly changing.
- The facade engine contains some fairly flexible rules for picking which segments of walls go where, so there’s a lot of potential to break up the order of facade walls.
- We can add more types of facade walls to a given facade without hurting X-Plane’s performance.
All of these changes can be put into an X-Plane update.
In summary, there are a lot of ways we can make the library more diverse and less repetitive, and as we see the library get used (and certain elements become over-used) we can add more variation to keep things looking fresh.
* For example, it wouldn’t make sense for me to ask Tom to make 50 variants of the administration building if almost no one places it in any airport. We need to see what kinds of assets get used the most and then make decisions.
