So…beta 1 is buggy as a bed in New York. I’m going to list these here in the hope of stemming the tide of bug reports:
These are broken in beta 1 and will be fixed in beta 2 – I’ve already fixed the code.
The new autogen is missing! 🙁 There was a bug in the code that makes the installation; 10.50b1 diligently installs the old autogen.
Crashes with some custom scenery.
Missing taxi lines – they’ll be back.
Floating objects – I did see this one during pre-beta; it’s now fixed.
The static aircraft are also not working; I am investigating this now, but I expect to have it fixed for 10.50 beta 2.
Finally, users are reporting crashes on startup with plugins; if you have this on OS X, please include the Apple crash report and not just Log.txt. I’m not sure what’s going on here, but it’s almost certainly a bug in 10.50b1 – we’re not changing any plugin compatibility rules, and the set of plugins affected is quite wide. (This bug is also not easily reproduced; I haven’t seen it with any plugins, it was not reported in private beta, and in one case the developer of a crashing add-on can’t crash his own add-on.)
Beta 2 will be out some time in the next few days.
X-Plane 10.50 beta 1 is live! You can download it by running the X-Plane installer and clicking “get betas”, but you will not be auto-updated for it. As is normal with our betas, there is not a Steam beta of it, nor will there be until we are at release candidates. (But Steam users can install a second copy of the free demo and update that to beta.)
Before continuing, I would like you to assume the lotus position and repeat the following mantra over and over until inner peace floods your body:
The comments section of the developer blog is not a bug reporter.
The comments section of the developer blog is not a bug reporter.
The comments section of the developer blog is not a bug reporter.
The comments section of the developer blog is not a bug reporter.
Ah…don’t you feel more calm already? I certainly do! Seriously though, the bug reporter is here; please use it! I cannot emphasize how much easier it is for us to triage bugs when they all show up in the same place. Random threads in forums about bugs get lost and don’t get fixed.
Release notes are here, but they are not necessarily complete yet. X-Plane 10.50 contained a huge amount of code change, so the notes probably need a few editing passes; something that Austin wouldn’t let meI didn’t want to hold up the beta for.
With any early beta of a major patch, I suggest that early adopters install it on a copy of their X-PLane folder and not the one they use to fly. This goes double for 10.50 because Jennifer, our Q/A head, is out of the office on a road trip. She was able to do a little bit of checking and we’ve tried to spot check it, but this release is more like the beta process from two years ago and not like 10.40 or 10.45. I suspect we’ll have the early stuff knocked out in a week.
There are already a few dumb bugs that have popped up: for some reason taxi lines are totally missing. I’m not sure when that happened because they were around for most of the beta. I’m also looking at a crash that JAR Designs sent me that looks like it could be pretty destabilizing (e.g. I broke the rendering engine). So…consider yourself warned.
Finally, our plan is to do one more airport collection from the gateway toward the end of the beta before we call 10.50 final. In the past we’ve done one airport collection per release, but for a long patch (e.g. 10.30, 10.40, 10.50) by the time we go final, hundreds of gateway submission are ready to go. We’re planning to take another batch in a few weeks, which will let people get fixes in to airports where the problems were revealed in 10.50 (e.g. even with the fixed 10.50 ATC the airport doesn’t work right).
First, it was great to see everyone who came to FSConn 2016! Here’s a video of the conference: if there is another video that has better stabilization I’ll try to post it.
Now about X-Plane 10.50: I did just fix my last beta-stopping bug. So in theory the first beta will be live tomorrow.
But that’s only theory! If the beta isn’t live, please refrain from being the 700th person to post “any ETA on the beta” to the comments section. The actual release date of builds is unpredictable because the existence of release-stopping bugs is unpredictable. (If we could be 100% sure there were no bugs, we wouldn’t need betas at all.)
First, we are making progress toward X-Plane 10.50. I sent out a private beta a few days ago; how soon we get to public beta will depend on how buggy the private beta turns out to be. (I am assuming that it will have zero bugs, because I have decided to not write any more bugs in my code. So…there, I fixed it.)
Coming in 10.50: X-Plane supports new manipulators.
In 10.50 you can add scroll wheel to any of the existing manipulators that takes one dataref. This is done via a second directive that sets the amount the dataref changes when the wheel moves.*
There are six new manipulators (they form a set) to support knobs and three-way switches. Each one takes a pair of commands and provides a consistent UI experience.
The no-op manipulator now takes a tool-tip, which lets you make tool tips for gauges and other unclickable geometry.
I want to make two things clear here:
This is support for these manipulators in the engine. This means that we can use them in our aircraft and third parties can use them in their aircraft. Adding these manipulators is a separate task, one we are working on, but which won’t be complete as of 10.50.
Third parties are welcome to use the new manipulators, and they are welcome to follow our internal usage guidelines. They are also welcome to keep doing what they are doing; none of this is binding, everything is opt-in. Nothing about this breaks compatibility with any existing aircraft.
Why Did We Add These?
We’ve had a long term internal goal of making the 3-d cockpit as usable and user-friendly as possible. We’ve reached a point where 3-d cockpits are the norm, and all of our new aircraft development is 3-d only. But you can’t deny that 2-d cockpits are incredibly usable from a user interface standpoint. How do you make 3-d usable?
We already have view presets to let you get to a particular cockpit view easily. Once you have a good view of the surface you want to interact with, the next step is to have a mouse gesture that’s easy to use.
This is where the new manipulators come in. Rather than describing a mouse gesture (drag, click, etc.) they describe a type of physical hardware, one of a rotating knob, left-right multi-way switch or up-down multi-way switch.
Because the manipulators describe the physical hardware and not how the UI should work, we can change the interaction mode based on user preferences, available hardware, etc.
One of the big UI questions is: should you change a knob by clicking and holding or dragging? I built a test airplane with some of each and the company was split down the middle. By using knob manipulators (and not click or drag manipulators) we can change the way knobs work in the cockpit for all airplanes with one change of the code, rather than having our art team redo every single manipulator in every single airplane.
I don’t know whether we’ll use dragging or clicking-based knobs – or whether a user preference will be exposed. But by having a higher level manipulator type we make this a small programming problem and not an unmanageable authoring problem.
(The new knob manipulator automatically uses the scroll wheel – since we know it’s a knob, we can figure out how the wheel should work. The new command to add scroll wheel to legacy manipulators is necessary to provide the data the sim needs to make the user interaction good.)
The new higher level manipulators also give us flexibility for new input devices. For example, if we someday want to support multi-touch tablets and track-pads, we could map a pinch-rotate gesture to a knob – since we know the manipulator really is a round knob (and not just ‘something that you drag’) we can know that a rotating gesture makes sense.
How Do I Add Them?
The new manipulators are already supported in code in the Blender 2.7, Blender 2.49 and and AC3D. The manipulators are released in the newest Blender 2.7 exporter; I need to post newer 2.49 exporters. I do not know if/when there will be a public release of the AC3D exporter, but I can probably find the time at some point to do one more compile.
All aspects of the new manipulators are opt-in; if you don’t change your airplane, its functionality should not change.
What Aircraft Use Them
I’ve buried the lead a little bit here: X-Plane 10.50 will have a heavily upgraded Kingair C90 and Baron B58 that will use the new manipulators. We have not (yet) upgraded the rest of the fleet, and this upgrade will happen over a very long time-span. The goal of 10.50 is to lay the groundwork and make cleaner user interfaces possible by making the new manipulators available to our art team and third parties.
The guidelines I’ve been advocating for our artists are:
Large things that move a lot like throttles are dragged via an axis that tracks the actual 3-d motion.
Yokes track via a 2-d XY manipulator.
Anything that toggles or has only two states is a single click, particularly for small things.
Rotary knobs and rheostats use the new knob manipulators. The mouse wheel can turn them.
Linear switches with three or more positions use the new left-right and up-down switch manipulators. The mouse wheel can click them.
There’s no reason why third parties have to use these guidelines; I post them only to show how we are thinking about usability. A more “3-d” approach is possible, e.g. drag a banana switch up and down to toggle it; my view is that for Laminar’s default fleet, which are the first aircraft users are going to use, single clicks provide a more direct and less surprising user experience.
For power users, having single clicks for switches may also mean you can get more done in the cockpit faster. (In real life, a pilot can reach up and flip four metal banana switches on the overhead panel very, very quickly.) We’ll still use dragging for big 3-d motions.
*This feature targets one-wheel clicking Windows-style mice. 2/3 of our users are on Windows, and Apple has shipped a wide variety of strange input devices, so the one-axis clicking mouse wheel is the most consistent hardware target for us to aim at. And frankly, I think it’s the most useful since you get clear ‘detents’ as you scroll things – good for changing a radio by one notch.
Signs in the hierarchy are shown as a rendered preview of what the sign will look like.
When you click on it (as if it was text) you get a WYSIWYG editor with two “text” fields where signs can be directly typed, and a palette where signs can be added by clicking.
I just fixed a problem in DDSTool: DDSTool was calculating mipmaps in sRGB space instead of linear space. This was wrong, but didn’t make a huge difference when grinding day-time textures.
It does make a big difference for LIT textures though. Let me show you.
Old: darker lit textures
New: brighter lit textures
That’s a night LIT scene (at PHNL I think) with some new autogen from X-Plane 10.50. (To answer your question, some of the AG has LIT textures, but not 100% of objects do.)
In the lower left corner are thumbnails of the raw textures – what is interesting about them is that they show the smaller-sized images in the mipmap pyramid of the image. And you can see that in the old image, the small thumbnail of the buildings is almost completely black – the building light has been lost with down-sizing.
Note that the buildings are a little bit darker in the old grind on the left but the tiny thumbnail is much darker. That’s because making mipmaps is a recursive process – each next-smallest-size mipmap is processed from the previous image; by the time we get to a really small size image, if we have lost brightness, the effect has really built up.
The result was that in the old grinds, as you flew away from the buildings, they’d get darker. In the new grinds, they stay at consistent brightness.
What Changed: the Math
Here’s the funny thing about images in sRGB color space (which is what X-Plane uses) – the mid-point between black (0) and white (255) is not 127 or 128. That’s too dark! The actual right color is 188 – pretty bright!
This happens because sRGB images are encoded in a non-linear manner for even perceptual spacing for humans, and our eyes are more sensitive at lower light levels. But the average between two pixels should be the average of the actual amount of light coming from the pixels. The half-way point of sRGB is too dark because a lot of numeric space in sRGB is spent in the dark regions.
The problem is that lit textures are made up of a few really bright pixels and a lot of black; when averaged together the wrong way the smaller sized images end up too dark, making slushy, dark, munged night lit textures at small sizes.
The solution (in the new DDSTool code) is to convert the colors to linear space, down-size the image and convert them back. There’s no change to how you use the tool – the images just look better at small size.
This is a tiny feature coming in X-Plane 10.50, but it will make a big difference for a few key plugin use cases: X-Plane will provide the current world model-view, projection, and aircraft model-view matrices to plugins via datarefs.
If you aren’t a plugin developer, or you don’t like matrices, or you don’t write your own OpenGL code, then the rest of this post is going to be boring, so go watch FrooglePete interviewing two funny looking guys. [Edit: link fixed – why that was pointing to airport flattening is totally beyond me!]
For the three of you still here: three matrices will be available:
The OpenGL projection matrix – that’s the one that is currently set up when your 3-d draw callback is called.
The OpenGL modelview matrix – we call it the “world” matrix, it maps the official X-Plane OpenGL coordinate system to eye coordinates, and it is also set up when your plugin is called.
The Aircraft modelview matrix – this is a matrix that maps aircraft coordinates (0,0,0 = CG, +X = right wing, -Z = nose) to eye coordinates.
You already are using two of these, the third is new. So who would even care? There are two use cases for this.
Stop Calling glGetFloatv!
Calling glGetXXX is bad. Modern Windows GL drivers send GL commands to a worker thread for execution, freeing up the rendering thread to keep going, improving framerate. But every time you ask OpenGL a question, our thread has to wait for that driver thread to catch up, slowing everybody down. The rule is simple: don’t call glGetXXXX.*
But there’s one case where your plugin might really need glGet: to get the current matrices for culling 3-d drawing.
This is where the datarefs come in – by reading our datarefs instead of calling glGetFloat, you can get the transform matrices without stalling the driver.
(If you have other glGetXXX that you can’t get rid of, ping me and I’ll try to find a work-around.)
Drawing On the Aircraft Without Jitter
The third matrix (the aircraft model-view matrix) is the matrix you would get if you translated to the aircraft’s location and then rotated around its orientation.
Here’s the key difference: when we do that calculation, we do the calculation in double-precision. We do this because the OpenGL origin can be tens of thousands of meters away from the aircraft, which in turn can be very, very close to the camera. In that situation, precision loss from single-precision floating point when multiplying together two very large matrices (that result in a very small matrix) results in apparent jitter when drawing.
The problem is: even if you wanted to do this calculation yourself in double precision, you can’t – the world matrix isn’t available to plugins in double precision.
So starting in X-Plane 10.50, the aircraft matrix is simply provided.
I did an experiment where I attached a green cube to an aircraft and then drew a blue cube at the same location from a plugin. With glTranslate/glRotate there was a ton of Z artifacts and slop that changed per frame because the two cubes were in slightly different positions. With the aircraft matrix, the green cube was invisible (except when disabling the plugin) because the blue cube overdrew it pixel-perfectly.
What about glGetError? Call this only in debug mode (to catch mistakes in your GL code); use #if to make sure you’re not calling glGetError in release mode.
I’ve been way behind on blog posts over the last few weeks. Basically, the more we are doing, the less I manage to blog about what we are doing. (Instead I put off writing a blog post until it’s really late and then decide at 11 pm that I’m too tired and I’ll do it tomorrow.)
So here’s a partial list of X-Plane 10.50 features. This is not even remotely complete, it’s just some “headline” features that I can think of now; the release notes will be comprehensive.
New Autogen: We have new US tall building art assets that will make cities look better.
apt.dat 1050 with Static Aircraft and New Models: A new revision of the apt.dat file provides information on parking spots so that we can place static aircraft models inside X-Plane, based on the library and rendering settings. X-Plane 10.50 will ship with a bunch of additional static aircraft models, and third parties can add more via the lbirary. WED 1.5 will have new features to edit this information.
For airports created before WED 1.5 (which is nearly all of the approved airports), we are working on tech to auto-upgrade the gateway airports to use the new static aircraft; third party scenery will simply not participate in the new feature until updated by the authors.
Global Winds Aloft: X-Plane 10.50 will use global NOAA data for winds aloft, rather than a US-only data source.
ATC Fixes: X-Plane 10.50 has a number of ATC bug fixes to make ATC a lot more usable. No more “you are off course!”
New Manipulators: We have added a few new manipulator types as part of an effort to make 3-d cockpits more usable. Yes, the scroll-wheel is accessible. (We have not rebuilt every 3-d cockpit in our fleet. The feature here is the capability in the engine, for us and third parties to use.)
Update King-Air and Baron: we have, however, redone the Kingair and Baron, fixing a number of issues and getting them to a whole new level for IFR flight. These planes use the new manipulators for their 3-d cockpits.
More Airports from the Gateway: as with all releases, we’ll include the latest airports from the X-Plane airport gateway.
Those are just the “big” things – there’s some huge number of other changes, some of which may be really important to some of our users. I still have about half a dozen items on my todo list to get to a 10.50 beta, so I haven’t worked up complete release notes yet.
