We should hopefully have a release candidate for 12.1.2 next week – this week the team was fixing crash bugs, and we’re down to trying to finishing up stability. Crash rates in the beta look good enough to ship. (Please consider turning on analytics – we don’t collect your personal data but we do record crashed vs non-crashed sim runs – this is how we know whether stability is getting better or worse!)

12.2.0

Dark Cockpits: Art team is evaluating Maya’s exposure fusion work. Generally things look better than the shipping product, but we discovered yesterday that the indirect lighting environment is pretty weird on cloudy days. We’ve been fixing bugs, removing old hacks we no longer need, and I’m optimistic that the update should be both better looking and closer to reality.

We also have some fixes to the PBR material model that may get X-Plane closer to Blender and Substance Painter 2. This is a double-edged sword: we don’t want to change the material model such that everyone has to repaint everything (that would be too much both for our team and for add-on makers) but we do want X-Plane to be as close to WYSIWYG possible to make development faster. Art is evaluating these changes too.

We’re targeting 12.2.0 (a “major free update”) for these changes so we can run a substantial alpha and beta program and give add-on makers time to report bugs.

12.1.X

ATC, Weather: we have two minor releases before 12.2.0 making their way through testing. The first is ATC with SIDs and STARs – as of now it looks like that will ship next, but all releases are subject to change based on bugs.*

The other update is a weather update, and it looks like it may have some substantial features:

• New in-cockpit weather radar, with SDK support.
• Fixes for real weather bugs, including jumps in pressure altitude (which are driving the autopilots crazy) and some fixes to cloud visuals.
• Plugin-controlled weather across multiple locations.
• Better weather sync over the internet.

As of now the weather branch also has network sync of trucks and jetways to external visuals. This only affects users using external visuals but for those users, it’s a big feature, and it’s also an important foundational technology for us.

* In the past we have announced “X” is next and if that code was buggy, we’d just delay shipping anything until we fixed it. We’re trying to be more flexible and ship what’s ready first, so good code doesn’t have to wait for unrelated bugs.

The post Around the Office: Friday the 13th Edition appeared first on X-Plane Developer.

Websocket-To-Me Time

Besides fixing bugs, X-Plane 12.1.1 enables X-Plane’s web API*. Basically we were asked for this so many times at FSExpo that Chris and Daniela put the remaining work on the fast track.

Our plan is to build several services into the web server; the web APIs will not be exact mirrors of the plugin SDK, but will cover enough functionality to build wide range of apps. We have plans for:

• Datarefs (shipping now)
• Commands (in developement)
• Initiializing Flights (in development)

Documentation on the new web APIs can be found here.

Doc-It-To-Me Time

X-Plane alum and fellow X-Plane-10-survivor Tom Kyler is back working on developer documentation for us, and has finished a first release on some of the new X-Plane 12.1.0 features:

• Windshield Rain Effects and Wipers
• Windshield Ice Effects and Defrosting
• Detail textures (both albedo and normals).

Tom has big plans for X-Plane’s documentation; one thing that’s great to see in these docs is really good illustrations based on real sample 3-d models and test projects.

The Devil Is In the Details

A detail texture is a repeating, high detail pattern that adds high-res detail to an otherwise lower resolution texture. Detail textures let us add fine detail at high resolution without using a ton of extra VRAM efficiently. We use detail textures with bits of “gravel” to make the runways look more realistic.

We introduced detail textures over a decade ago in X-Plane 10 to enhance ground detail around airports and in the new (at the time) autogen cities.

What we did not do was give them a good name. At the time we called them “decal” textures. This has turned out to be incredibly confusing, because in every other game engine ever, a high-res texture applied over the entire material (which is what we have) is called a detail, and a decal basically means “sticker that you stick on somewhere”. Detail textures make the ground look more rocky, decals add blood spatter and bullet holes to the walls in your zombie-shooter game.

So moving forward, we are going to try to call detail textures “detail textures” wherever possible, to be consistent with the norms of content creation. Tom and Maya will be updating labels in Blender and doc to be consistent about this.

For X-Plane 12.1.1, Maya has extended the detailing system in two ways:

• Detail textures work on OBJs and not just in the scenery system, so aircraft authors can add detail too.
• Detail textures can affect the bumpiness of normal maps and not just the color of albedo textures, so detail textures now interact with the lighting model in realistic ways.

You can get the 4.3.3 beta XPlane2Blender plugin here to use the new detail textures. Maya is planning on a release Real Soon Now.

* Please note that while the dataref API does use websockets, most of our web APIs are conventional REST requests over HTTP. I did consider “The X-Plane developers never REST..until now” as a section title.

The post Webservers, Documentation, and Terrible Titles appeared first on X-Plane Developer.

Author-controlled de-icing has had a series of bugs in 12.0.x. For 12.1.0 we’ve gone over it with a fine tooth comb; Alex ran the above tests with our Kingair, which has the unusual case of two overlapping de-icing zones. We’ll have updated docs, Blender exporter support, and builds for authors.

Some tests of real weather. In the first pic, the sky says clear but there’s a distant cloud…because the weather report is local.

Water turbidity is fixed for 12.1.0 and I am finishing documentation for authors. It looks like Oscar’s work on Ortho4XP is on GitHub. Please note that X-Plane 12.1.0 does not improve X-Plane 11 orthophoto water compatibility; v11 packs will only have 2-d water because their meshes are not triangulated properly for 3-d waves.

Based on the progress we done this week, I am hoping we will be able to test these features next week and start a private alpha in our developer lobby.

* Please note: these are internal pics from the developers that I am posting while the marketing team is too far away to object – literally what we were passing around while discussing the features. Don’t panic over FPS; the sim is running a debug build in those real weather pics, for example.

The post Finishing 12.1.0 Features appeared first on X-Plane Developer.

The really big change we are making to base meshes is to go from a vector-centric to a raster-centric format. Let’s break that down and define what that means.

Vectors are fancy computer-graphics talk for lines defined by their mathematical end-points. (Pro tip: if you want to be a graphics expert, you just need the right big words. Try putting the word anisotropic in front of everything, people will think you just came from SIGGRAPH!) DSF started as an entirely-vector format:

• All 3-d clutter is defined by lat/lon locations, so we have the vector outline of polygons, autogen blocks, etc.
• The base mesh is pre-triangulated, so most base-mesh features are defined by the corners of the triangles forming lines (e.g between land and water).

This isn’t the only thing DSF does – we added raster capabilities and there is e.g. raster sound and season data in X-Plane 12, but DSF is fundamentally about vector data – saying where the edges of things go exactly.

This was great for a while, but now that we have more and more vector data (complex coastlines, complex road grids, complex building footprints) the DSFs are getting too big and slow for X-Plane.

Raster data is any data stored in a 2-d grid. This includes images (which in turn includes orthophotos) but it also includes 2-d height maps (DEMs), and the 2-d raster data we include in DSF now (e.g. sound raster data, season raster data etc). Any time we store numbers that mean something in a 2-d array, we have raster data.

Raster data has several advantages over vectors:

• Raster data is what the GPU wants to consume.
• Raster data has really good LOD characteristics for close detail with long view distances.
• We can put more interesting and dense information into a raster tile without it getting bigger.

Twenty years ago, when I first worked on DSF, computers didn’t have the capacity to use lots of raster data – this was back when 8 MB of VRAM was “a lot”. But now we no longer need to depend on vectors for space savings.

Raster tiles are raster data broken into smaller tiles that get pieced together. Raster tiles have become the standard way to view GIS data – if you’ve used Apple Maps or Google Earth or OpenStreetMap or any of the map layers in WED, you’ve used raster tiles.

Raster tiles have a bunch of advantages too:

• They have really great LOD/VRAM usage properties.
• They can be loaded incrementally.
• They provide an easy way to vary resolution and let authors skip providing data that they don’t need to provide. (E.g. “forest” raster data over the ocean? Just don’t provide any tiles!)

So our plan for the next-generation base mesh is “all raster tiles, all the time” – we’d like to have elevation data, land/water data, vegetation location data, as well as material colors all in raster tile form. This would get us much better LOD/streaming characteristics but also provide a very simple way for custom scenery packs to override specific parts of the mesh at variable resolution with full control.

Raster tiles are not the same thing as orthophotos. A raster tile is any data contained in a 2-d array, not just image data cut into squares (e.g. orthophotos). So while a raster-tile system may make it easier to build orthophoto scenery, it does not mean that the scenery can only be orthophotos.

The post We Are All Raster-farians Now appeared first on X-Plane Developer.

Private Alpha Builds Soon

As with all past X-plane 12 patches, we are planning to do a private “alpha build” test run with the developer lobby before public beta. We do this both to find out about add-on compatibility and to get the worst bugs fixed with a smaller test group. As of this writing, ATC is at the end of bug fixes, the last graphics changes are being tested, but my weather work is still mid-development.

New Toys for Scenery Developers (and Aircraft Modelers)

This release turned out to have a lot for scenery developers:

• Water bathymetry and turbidity should be sorted out, making orthophoto base meshes with 3-d water possible.
• The material system now features normal-map decals. These decals add high-frequency ‘texture’ to a surface by perturbing the normals (direction of light bounce) instead of just “painting’ them. This means better looking materials at different lighting angles.
• LOAD_CENTER is now usable on OBJs. This means you can set the resolution of an OBJ to be based on distance to the aircraft (just like draped polygons and orthophotos); I think this has the potential to ensure that “land mark” OBJs (models used exactly once) are at their highest resolution when the user is near them without hurting VRAM in general.
• If it passes test (crosses fingers), particle systems can be used directly from DSF objects.

The entire DECAL system (existing and new normal map decals) are also usable in OBJs for aircraft as well, and the particle system has received some upgrades that can be used everywhere.

One warning: the old “smoke puff” directive for OBJs from X-Plane 8 is now inoperative; with 12.1.0 we finally removed the old particle system completely. I suggest using the new particle system as it will give you real control over what kind of smoke comes out of your models.

New Plugin APIs

Two new plugin APIs are planned for 12.1.0:

• New navigation APIs
• An extension to XPLMAvionics so add-ons can create their own glass screens.

We are still putting finishing touches on the avionics APIs now, but this tech is very close to complete, and definitely usable.

Unfortunately we will not have a low level weather API in 12.1.0 – R&D on this is ongoing, but at least in better shape than it was before due to fixes to the internal weather code.

The post A Few Notes on 12.1.0 for Developers appeared first on X-Plane Developer.

Here’s the key point for the first one:

A new scenery format is not the same as new scenery.

This can be confusing because we haven’t changed either our scenery file formats or our scenery in quite a while, and often the two change together. Let’s break this down.

A scenery file format is the way we represent scenery in our simulator. It consists of several things:

• A file format specification, describing how scenery data must be encoded.
• A file parser inside X-Plane that can read those files.
• A renderer inside X-Plane that can render those files.
• Tools that help people encode those files.

My first work for Laminar Research (two decades ago) was building all of those things: I invented DSF files, wrote the DSF reader inside X-Plane (DSFLib), worked on the rendering engine, and created the tools to write the files (DSFTool).

When we talk about just the scenery, this is the final rendered files that people fly with. Remember when we shipped 60GB worth of content in 12.0.9? That was new scenery rendered out with all the latest and greatest data.

X-Plane ships with the “global scenery” – a set of about 18,000 DSFs that ensure land everywhere from 60S to 75N. But this is not the only scenery out there – there’s TrueEarth, HD base meshes, SimHeaven, and scenery made with Ortho4XP.

Lots of people can make scenery, often in many different ways (using land class, orthophotos, autogen, etc.) but all of that scenery must be in X-Plane’s scenery file format, e.g DSF.

The scenery is the turtle and the scenery file format is the shell. The scenery can only be as complex as there is capacity in that file format (shell).

So the first part of my talk was a tour of how we have outgrown DSF, and pointed out that there are some things that DSF can’t do. For example, several add-on makers want to stream custom scenery, but DSF makes that basically impossible. DSF also isn’t meant for really high detail vector data, so we’ve been having trouble using all of the latest OSM imports.

The second talk discussed our plans for a replacement to the base mesh file format, which is based on raster tiles. This part of the talk said nothing about what kind of scenery we (Laminar Research) would make, which raised a lot of questions.

But now that you understand the the turtle and the shell, you have a lens to understand what we’re saying. This wasn’t an announcement of next-scenery, only an announcement of a bigger shell that will make that next-gen scenery possible.

So the next-gen scenery format is all about potential. The scenery file format limits what is possible for all scenery (both what is built into the sim and add-ons), so we want to raise those limits quite a bit in the next-gen base-mesh format.

The way we are doing that is by moving the base mesh from a vector-centric approach to a raster-centric post; I’ll break that down in another post.

The post The Turtle Needs a New Shell appeared first on X-Plane Developer.

So that’s not great. The truth is the X-Plane team is larger than it was in the v10 days and I spend most of my communications time talking to the internal team and third party developers.

I’m going to try to post once a week here. This sentence may be an embarrassing monument to lofty but impractical goals in another four months, but putting it in writing is a way to commit to it, and it won’t be the most embarrassing thing I’ve ever done.

Two Quick Store Notes

We announced the X-Plane Store plan in Montreal; Dellanie’s got a great FAQ there, but here for developers I just want to make two points clear:

1. We are not locking X-Plane down. I totally get why people might think this because the iPhone app store is (1) a very prominent way to do in-app purchase and (2) the iPhone is locked down. But we are not doing that. All of the ways you get stuff into X-Plane will still work, including add-on installers, dragging folders around, you name it. Going through the store is not a requirement, and everything that works now will keep working. You won’t have to pay for freeware or re-buy anything.
2. You will not have to be online all the time. Our current policy is that if you have an online license (an “XDD key”) you have to log in every two weeks or more to renew it. We are not going to switch to “all online all the time” – we know that this is impossible for a lot of our users and we consider maintaining this “renew the key every now and then” policy to be a requirement.

What’s Next: 12.1.0 and 12.2.0

We have two “big updates” planned right now:

• 12.1.0 will ship next and is primarily a graphics release. RCAS, bloom, DoF, shadow softening, cloud shadow fixes, new decals, you get the idea. This update will also address a number of real weather bugs and transition to the new real weather servers.
• 12.2.0 will ship after 12.1.0 and is primarily a flight model release. All of Austin’s advancements in prop blade dynamics, stalling and turbulence, etc.

Both releases will have a bunch of other stuff too; they’re big patches. I’m pointing to the graphics/FM divide because the decision to push one of graphics or physics in each patch is intentional to keep the scope of the beta under control.

We are aiming to get 12.1.0 into private testing this month.

What’s Up, Docs?

Probably only three people on Earth care about this, but after a decade (more walk of shame) I was trolled into updating the .net file format specification. So if this is interest to you, I apologize both for the delay and for the pain you are about to suffer. The road art file format in X-Plane is incredibly complicated and I don’t actually recommend anyone try to hack it, but it’s also not meant to be a secret.

Scenery, Now and Future

I am working to get water and orthophotos sorted out, hopefully for 12.1.0. We will also have a DSF recut (hopefully for 12.1.0 but maybe for 12.2.0) to address gateway airport boundaries and runway undulations.

In Montreal I discussed a little bit about the future of the X-Plane scenery system, but that’s complex enough to warrant another blog post.

The post Blog Post Walk of Shame appeared first on X-Plane Developer.

But there are two graphics bugs we already have fixed in-house which should relieve some 12.06/12.07 pain:

• Running out of memory mid-frame. Turns out if you got into a fairly tight situation VRAM wise (and we try to do that to max out the texture res you can have) then X-Plane might run out of memory trying to draw trees and…melt down like a toddler who can’t have any more candy.
  
  We have an interim fix: allocate memory statically so we always have it. In a future update we’ll reuse memory from other parts of rendering to be more efficient.
  
• Popping out a window causes a big slow-down. When the arrangements of windows changes, we might need to allocate more VRAM for rendering. This is not a fast process – we have to halt all rendering, throw out the old memory, compact things, allocate new memory, and if a DSF is loading while this happens, the DSF loader is using up memory as we are trying to reallocate the windows, which can mean compacting memory again, paging down textures…you get the idea.
  
  The fix is pretty simple: don’t do this if the popped out window doesn’t require more VRAM. Most of the time, this is the case, so this is an easy fix for a silly bug.

Integration work for the next update is going on now and I’m hoping it will be done next week. More details soon!

The post Two Pain Relief Fixes Coming Soon appeared first on X-Plane Developer.

Last week we shipped X-Plane 12.06; since then we have found a few straggler bugs; like typical lARRge patches from the days of X-Plane 11, a few bugs escaped us until after final, including some crashes we could see in the auto reportARR.

While it’s not great to be shipping a “hot patch” to our release, it is pretty fantastic to announce X-Plane 12.07 ARRsea 1 on International Talk Like a Pirate Day (the 19th of septembARR). The rest of this blog post only gets worse; you’ve been wARRned.

12.08 Is The New 12.07

Internally, nobody is happy about this, but the hot patch bumped all of our version numbers. So the new road map looks something like this:

• 12.07: hot patch of 12.06.
• 12.08: coming soon. Flight model and systems, ATC and Networking
• 12.09: more graphics and real weathARR fixes.

12.08 (né 12.07) is almost completely integrated and should be ready for private testing as soon as 12.07 is settled.

Why Wasn’t I Notified

Since 12.07 is a new version, you won’t be auto-updated to upgrade from 12.06 while 12.07 is in testing; run the installer, update with “get betas” checked and you can get 12.07.

Crash Fixes

12.06 shipped with more sensitive internal detection for numeric problems. This is how we run the sim internally all the time – the goal is to find and squash bugs fast.

Unfortuntately there are sections of X-Plane’s simulation that are:

• Not present in an aircraft (e.g. the real aircraft doesn’t have X)
• Not expensive to run, CPU-wise
• Not visible to the user (since the aircraft has e.g. no gauges to show these systems.

As it turns out, these systems are often happily running away in the background producing absolutely bonkers values; with sensitive numeric checking, the sim can crash due to problems in a system that nobody cares about.

For 12.07, I solved the problem by muting the alarm. My expectation is that we’ll have sensitive numerics in most betas, turn them off in the releases, and work through the systems code over time. (The priority on this isn’t super high because the systems aren’t consuming framerate – if they were we’d see them in our profiling.)

The other area where we saw increased crashes was with TCAS plugins. 12.07r1 has better logging and shouldn’t crash as much – the goal here is to not brick third party add-ons.

Other Bug Fixes

Multi-monitorARR: data output was not working in full screen configurations, fixed now, and manipulators work for multi-monitor systems.

OpenXARR: HP Reverb fixed, and we finally figured out why the white board would sometimes disappear. (It wasn’t gone, it was just 20 km from the hangARR.)

GARRmin Bezels

X-Plane does not have a built-in way to remove the bezels from the pop-out avionics. To solve this, some of our user and some add-ons edit the ARRtwork inside X-Plane’s “resources” folder, setting the bezels to clear.

X-Plane 12.06 introduced new bezel variants for the G1000 to cover all of the real-world panel button configurations. This fixed the bug “the real aircraft does not have these buttons, but when you pop the panel out, the buttons appear and do nothing.”

A side effect of this is: those aircraft using the new bezels use new art files, so the hacked up no-bezel art files on longer work.

This is not a bug for us to fix; if your add-on works by modifying the internals of X-Plane, we cannot guarantee that it will keep working even when we change the sim. (The only way to make that work would be to never change the sim.) You can work around this by modifying the new bezel files.

In the future, our plan for this is to provide a real way to hide bezels in the sim as a built-in part of the UI, which should make hacking unnecessary.

What Comes Next

Hopefully 12.07r1 will be “one and done”; if so, we’ll move on to private testing of 12.08 almost immediately.

If you are a third pARRty and your add-on has problems with 12.06, please tell us four weeks agoas soon as possible!

The post X-Plane 12.07 ARRsea 1 Has ARRived appeared first on X-Plane Developer.

If this sounds like you, you are welcome to give this a try right now by upgrading to 12.04b3, going into the Graphics settings and checking the “Use Zink plugin bridge” check box. Restart X-Plane and if everything goes to plan, X-Plane should look exactly the way you are used to but most importantly your plugins should look right and your performance might be better too. Because Zink is built on top of Vulkan, it’s only available to Windows and Linux users and is not applicable to macOS and Metal.

If you only take one thing away from this blog post, I hope it’s this image showing the difference between native Vulkan/OpenGL interop as well as Zink interop gives you an idea of why we are excited about this:

Now that I hopefully have your attention, let me elaborate how we got here and what this means for both users and developers. First of, Zink is actually a graphics driver that sits between plugins and X-Plane and translates plugin OpenGL rendering into native Vulkan commands that get executed by the same Vulkan device that X-Plane is using for rendering. Of course, X-Plane itself no longer uses OpenGL, but it’s is still very important for plugin development. A long time ago, when X-Plane was still OpenGL based and the plugin SDK was first made, it seemed like an absolute no-brainer to just expose the X-Plane OpenGL context to plugins directly and let them handle all their drawing needs themselves. It gives the most flexibility and control over everything, and it also makes it easy for the SDK because there is no need to make fancy drawing routines to be used by plugins.

Fast forward to the Vulkan and Metal port and we suddenly have an issue: Neither Vulkan nor Metal is OpenGL, but there are now hundreds of plugins out there that all assume X-Plane uses OpenGL and the OpenGL context is there. Killing OpenGL for plugins would mean countless plugins would stop working, requiring potentially lengthy update processes or maybe they’ll just never work at all again because the author lost interest in X-Plane or developing the plugin. This is how we ended up with the OpenGL Bridge in X-Plane 11.50: We create a real OpenGL context, share some memory from within Vulkan to that OpenGL context, then let plugins continue to draw how they used to do. X-Plane takes care of all of the heavy synchronization and resource creation rules under the hood and everyone is happy. Everyone? Well, no, not quite…

The problem with Vulkan/OpenGL interop

The big problem with Vulkan/OpenGL interop is that it relies on the driver to support this properly. As it turns out, driver support for this is flaky at best, if you own an AMD card you can probably tell long stories about issues. The most prominent one is flickering or altogether missing rendering, in which case plugin drawing is either completely missing or flickering in and out of existence making it basically impossible to use plugins. The other issue is performance, captured in the screenshot above, where the OpenGL bridge adds almost 10ms per frame, although I have seen numbers as bad as 30ms per frame. For reference, 33ms is the time one frame can take at most to reach 30 FPS! This wasn’t always the case, it used to run much better, but driver regressions are a real thing and this isn’t really something the hardware vendors test. Not that I can be too mad about this, X-Plane is one of the very few applications that uses this feature at all. Despite having filed numerous bug reports with the vendors, unfortunately the problems were never completely fixed, so even during the 11.50 days we started thinking about alternatives. During the X-Plane 11 days it was at least somewhat easy to tell users to switch back to OpenGL to avoid the flickering, even though that usually meant a hit in performance because the Vulkan backend was just so much faster.

There are of course other open source OpenGL drivers out there that aren’t Zink. The most well known one is probably Angle, a implementation of OpenGL ES by Google. None of them work for us however, because of another terrible decision made many years ago: X-Plane has always used a compatibility profile OpenGL context. What that means doesn’t matter, but the end result is that X-Plane and by extension plugins, rely on the existence of OpenGL commands from the 90s! Most modern implementations of OpenGL will happily ignore everything from the compatibility profile because it’s a nightmare to implement and doesn’t map very nicely to modern hardware at all. But a lot of plugins make use of these old features and rely on the fixed function pipeline. Which, by the way, is also the reason we didn’t just expose Vulkan or Metal to developers. Writing either a Vulkan or Metal renderer requires a ton of overhead, is deeply complicated and error prone. Writing correct code requires testing on different hardware, reading a few thousand pages of specification text and having a good understanding of the underlying hardware. Most plugin developers don’t venture past the fixed function pipeline, it would be absolutely unreasonable to expect them to spend the time and effort involved in this.

What’s a Zink?

Luckily we don’t have to throw any developers into the deep end because there is Zink. Zink is part of the Mesa open source project and is a backend for the Gallium driver, which is the OpenGL frontend provided by Mesa. Okay, lots of big words here, let’s simplify this a bit: Gallium implements OpenGL 1.0 to OpenGL 4.6, which basically means “all of OpenGL”. But it doesn’t actually do anything with it, it just does all of the heavy lifting required to make OpenGL work. Backends are what actually turn the intermediate data that Gallium produces into real commands to be executed by a GPU. There are a lot of these backends: For example there are multiple software renderers that just use the CPU, there are implementations that talk to AMD GPUs, Nvidia GPUs, Intel GPUs, things I never even heard about, it’s all there. But among all of those backends there is also Zink. Zink just takes what Gallium produces and builds Vulkan commands out of it to be executed by any Vulkan capable hardware. This is what makes Zink so great for us, it’s a real OpenGL implementation that includes all of the hard and complicated bits we need to make plugins work.

Of course I’ve made it sound easier than it really is, “just” writing a Gallium backend that magically speaks Vulkan is a lot of hard work. The unsung hero of all this is Mike Blumenkrantz, head honcho and lead developer of Zink. He’s spent years getting Zink to the point it is at and is contentiously working on improving it, both in terms of supported features as well as performance. He’s also an absolute legend and none of this Zink interop X-Plane stuff would exist if it wasn’t for his help, not just in getting Zink to where it is but also answering tons of our questions during the integration. Big shout out to Mike! While I’m doing shout outs, it would be unfair of me to not also mention AMD. While they are partially the reason we are here today, they also provided us with help and driver updates to make Zink work together with X-Plane and every engineer of theirs that I have met along this journey has been nothing but kind and helpful.

I’m a user, how does this affect me?

If you are on X-Plane 12.04b3, open your graphics settings and enable the Zink backend. By default we run with the native OpenGL backend for compatibility reasons, although the long term goal is to switch to Zink exclusively, but not anytime soon. There is a chance some or all of your plugins will explode, we’ve done testing with third party developers on this, but the area touched by this immense and we can’t test every plugin out there. If it breaks, no worries, please file a bug report and let us know, fall back to the native OpenGL backend and try again in the future. The idea behind Zink is to make it as much a “it just works” thing as possible, but it’s the first step and if it isn’t perfect right out of the gate, I hope you have some patience with us. I’m saying this because like I said, the surface area touched is immense here and shipping a whole graphics driver with an application isn’t really something super common and, as I have found out, sometimes breaks stuff.

The good news is that Zink is open source and we are building it ourselves, which means that for the first time we can actually see under the hood when things explode. I have very high hopes that this will help us track down issues much faster than usually. Normally drivers come with all debug data stripped, so a few times I have seen bugs that just end somewhere in the driver with no way to tell what even happened or how to reproduce it. Sometimes we don’t even have any information at all because it got so thoroughly muddied.

I’m a developer, how does this affect me?

Well, same as above: Test your plugins, file bugs, be patient. But also, there are a few things you might want to be aware of in general:

First, X-Plane now finally lets you enable a debug GL context. If you run X-Plane with --debug_gl, X-Plane will make a debug GL context for you and then wire up the necessary callbacks. By default it’ll print all messages into stdout and errors get a big in sim pop up. But you can always redirect it to something of your choosing by calling glDebugMessageCallbackARB() with your own callback. Please don’t ship plugins with a handler enabled though, because it might lead to other developers not being able to set their own callback as there can only be one. The debug GL context is available when running through Zink and also the native GL driver.

Gotcha wise, there are two that I’m aware of:

• In theory you can make a shared GL context for background GL processing, but it might not be 100% stable. I’m still trying to track down an issue somewhere in the stack that leads to resources being incorrectly deleted, so if you run into issues with a shared GL context, this might be it. Please try it though!
• Don’t disable and/or enable GL_FRAMEBUFFER_SRGB, this will lead to all subsequent rendering to disappear. This bug I have tracked down further into Mesa and the problem is that the driver will create a copy of the image to add or remove the sRGB bit, but it never ends up copying the result back over. In theory this should be handled by just a view on the same image without any copies, but either way this is currently broken.

If you want to test Zink as part of some CI solution, you can also run X-Plane with --zink or --no_zink through the command line and it’ll override whatever was set in the graphics settings.

I’m on macOS and I feel left out

First of all, I’m sorry to hear that. 12.04 has great things for macOS users as well that I’m sure you’ll love. Long term, we are having ideas of running Zink on macOS too, just this time on top of Metal. GL on macOS is already emulated through Metal, it’s just done by Apple without visibility or ways to tap into that. We have a bit of a pipe dream of running plugins on top of Zink on top of MoltenVK on top of Metal, but this is purely in the ideas bin right now and no code for this has been written. There would be two advantages for this approach though: First, Apple has deprecated OpenGL already in macOS and while I do believe they will continue to support it, lest their pro users will climb on their roof and shout bloody murder, they clearly have no interest in expanding OpenGL support any further. Secondly, if we get OpenGL bridging down to just Zink on all platforms, it’d be a boon for developers because they can target just one OpenGL implementation and cover all platforms in one go. It’d also finally bring OpenGL 4.6 support to macOS, which is currently held back to OpenGL 2.1.

The post Addressing Plugin Flickering appeared first on X-Plane Developer.