Update: this driver bug has since been fixed – see here.
If your X-Plane screen looks like this with HDR on, you may be running the new Catalyst 13-12 drivers. If you can, back up to the Catalyst 13-9 drivers to get back HDR mode.
(If you have a really new AMD card, you might not be able to run 13-9 – in that case please turn off HDR until AMD has a fix.)
This is a continuation of this problem – what’s new is that the 13-12 drivers are WHQL drivers and not just beta drivers.
Thanks to the users who reported this to me. I try to keep an eye on all driver combinations, but the help is appreciated!
Update: this bug has been fixed – see here for details.
For X-Plane users with an AMD graphics* card on Windows or Linux: there appears to be a bug in the 13.11 drivers** that cause corruption in HDR mode; the symptoms are square artifacts of missing clouds and missing windshield in aircraft.
If you can run the 13.9 drivers, stick with those; if you have one of the new Rx 290 cards and you must use newer drivers, turn HDR off for now.
These bugs are Win/Lin only – the Mac AMD drivers don’t have this problem.
* AMD seems to have fully rebranded ATI’s GPUs at this point, so I guess I should get used to writing ‘AMD Radeon’.
** The bug could very well be in our code, but since the code worked on old ATI drivers and a number of other driver stacks, it may very well be a regression in the driver itself. We won’t know until it’s fixed. And even then, maybe we won’t know.
If you’ve survived downloading the rather large 10.25 patch and you want to download even more data, good news! Alpilotx has just released version 2 of his X-Plane HD Mesh Scenery.
His scenery pack is a donation-ware recut of North America and Europe. Alpilotx’s HD scenery use the latest OSM and other global data sources, and are cut with the latest DSF generator; thus they contain better DSF generation with newer data. Alpilotx then cranks the mesh settings well beyond what we can ship with the global scenery (which must fit on a DVD set and not fill an entire SSD), bringing out wonderful terrain definition and other detail that we have to cut down for the global scenery that ships as a default with the sim.
One of the cool effects of cranking up the base mesh detail: it brings new detail to the terrain shading. In X-Plane 10 we moved the process of altering terrain with slope (from forest to grass to rock, or whatever the artist defines) from a CPU process calculated ahead of time to a shader process run on the GPU. The result is that more detailed meshes actually produce better shading, as the shading responds to the 3-d detail.
If you have a computer that can run them, these meshes look great, and they get you a source of recut DSFs now.
The recut DSFs that Laminar ships will be based on the same DSF generation code improvements and the same new data, but the resolution will be reduced to produce files of similar size to the default scenery we already ship. We have not decided exactly how we will ship recuts; I think that really important fixes (e.g. Sydney with the harbor fixed) will be automatic updates; I don’t know about a wider scale yet.
X-Plane 10.25, out now, is a big update by size – 1 GB compressed, if you were current to 10.22. The result on our servers is, well, higher than normal load. (That nearly flat top-out at 100 mbits is 10.25 kicking.) We’ll keep an eye on things; I expect that server load will settle down in the next few days, once the initial rush of auto-updates goes through.
X-Plane 10.25 went final today; if you’ve launched X-Plane you already know that from the auto-update notice. With this update we shipped the first set of lego-brick airports, and new urban and natural terrain. We also updated WorldEditor to version 1.2.1 during this beta run.
The Necessity of Saying Too Little
This post, like all “road map” posts, will almost certainly be too vague for your liking. What you’d really like to see is a list of features and a list of dates, e.g. “we will ship X on this day, then Y on this day” for future X-Plane patches. Unfortunately I cannot provide that. I also can’t expect you to be happy with only vague release notes. But I have to hope that you can at least see what things look like from the other side of the table; if you were in my position, you might not post too much either.
There are a few problems with announcing new features way in advance:
The penalty for being wrong is a lot higher than the benefit of being right. If I can predict our future features directly, at best everyone gets excited and impatient for the new release. But if my prediction is wrong, it will make everyone very angry. So if there is any risk that a feature might not come out when we think it will, I think everyone is better off without pre-announcements. (We are not the only tech company or even flight simulation to maintain this policy.)
It is really hard to predict when new features will come out for technical reasons. Or put another way, if what we are trying to do is new and novel, there aren’t good things to compare to in order to estimate schedules. We thought we’d ship real-time shadows in X-Plane 9.0, but when 9.0’s release date came around, they just looked awful; the technology we had picked was not good enough. So we put them on ice, re-coded them and released them for X-Plane 10.0. That kind of thing is hard to predict; we had working shadows for v9, they were just horrible. In hindsight I’m really glad I didn’t pre-announce “X-Plane 9 will have real-time shadows” – everyone would have been disappointed by the lack of shadows, and it would have drawn away from the real-time water reflections we shipped.
It’s also hard to predict when new features will come out for business reasons; if a feature isn’t being worked on “right now”, there’s the risk that some kind of high priority emergency will come up. For example, during the X-Plane 10.25 beta run, we realized we had to recut our installer, because it had a crash bug on certain OSX versions. That time wasn’t in the estimate, but the installer crash was an emergency. Had I said “X-Plane 10.25 will go final on November 15th”, I’d have been wrong, and you’d be mad that we had mislead you.
So my first point is that software is unpredictable, and I think it’s better to keep quiet until we’re sure we know what will happen. Thus, no statements about what we will release six months from now.
Guidance Is Important
If you develop third party aircraft, you’re probably jumping up and down at this point, going “are you freaking kidding me? I can’t plan my business this way!!!” And you’re right. What I can try to do is provide guidance about technical challenges that you might face as an author.
Our overall goal is to maintain add-on compatibility within a major version run. If your add-on follows the rules, we’ll try to avoid changing the rules. But sometimes add-ons bend the rules, and updates can affect those add-ons. I try to provide hints as to what is going to matter, far ahead of time.
For example, X-Plane 9 introduced the concept of ‘glass’ objects in an aircraft. Glass objects solves the problem of getting your cockpit windscreen and 3-d interior to render in the right order, which is nice. But it also is necessary to get high quality translucency in HDR mode in X-Plane 10. So we tried to get the ‘glass’ option into v9 and then encourage developers to adopt the new scheme, as it provides both better results and future proofing.
Big and Small Patches
Our patches to X-Plane come in two sizes these days:
Big patches have long betas (4 weeks or longer) and make significant change to the sim; we need the beta time to find and fix bugs introduced by the new changes.
Small patches change a very small amount of code; we test them for only 1 or 2 weeks. Because the amount of code change is very small, we don’t have to worry as much about strange bugs we didn’t expect.
X-Plane 10.10 was a (very) big patch, and 10.20 was a big (albeit not very chaotic) one. The bug fix releases (10.11, 10.21, 10.22) were all, of course, tiny – they just fixed 1 or 2 bugs that made it past beta.
X-Plane 10.25 is actually a small patch by our standards – while it provides a lot of great stuff for users (airports, cities, etc.) and it’s a big download data-size, the code changes are incredibly small; it’s mostly art files.
Future Releases
At this point our next “big” release planned is 10.30. We have a ton of stuff planned for it; it’ll be a big release, offer significant new features, and probably take quite a while in beta.
If you are a third party aircraft or scenery author, you will want to re-check your add-ons on 10.30. I know that this takes time away from working; we try to not have a “retest everything” patch that often; the last one was 18 months ago. Remember that if you find something broken, you will need to report a bug, not change your add-on!
(As a side note, I hear this from third party developers all the time for bugs that have been in the sim a while: “You mean no one else reported this bug?” Everyone thinks someone else will report a bug; some bugs that are visible only on third party content thus never get reported. Assume that no one has reported a bug – you’ll often be right!)
We may do at least one more small release before 10.30, either for DSF recuts, more lego brick airports, or to fix any crash bugs that we find. But at this point no code features are going into the sim before another “big” patch – small patches will be for art.
In terms of timing: I can say with some certainty that 10.30 will be next year, not this year – there are less than six weeks left in 2013, and we won’t be ready to public beta a big patch that soon. I think it is possible that we’ll have one more small patch in 2013, but we don’t have a firm plan yet.
The DSF recut work is mostly done, but I am going to wait for AlpilotX to release his latest HD scenery; his scenery is developed using the same tech as the global scenery, so it should give us a good idea as to whether the recuts are ready or need bug fixing.
I’ve marked WorldEditor 1.2.1 as final. If you are a WorldEditor user, please upgrade from 1.2 to 1.2.1. Besides fixing a bunch of bugs (including annoying usability bugs), it changes the format of the zip files for submissions to the global airports to a format that is a lot easier for us to handle on our end.
The next version of WED will be 1.3 and will include more usability features; we’re not sure what else will go in that bucket or when we’ll cut it off and kick it out the door.
I have a lot to cover here – a little for everyone I think.
10.25 Release Candidate 1 Is Up
If you are a third party developer using 10.22, and you haven’t participated in 10.25 betas, please go do so now. You can get the beta by running the installer and clicking “get betas”. (If you run the beta, you are auto-notified to update.)
This build sneaks in object-killing in Plane-Maker; thanks to the aircraft developers who took time to privately test this feature last week!
A Fix to the Plugin SDK
This section is just for the programmers. I investigated a three-way conflict between X-Plane 10.25, Gizmo 64-bit and the new 64-bit XSquawkBox, and what I found was a bug in the C++ wrappers that ship with the X-Plane SDK headers. XSquawkBox was using them, but they were not correctly updated for 64-bit.
They are now. So if you use the “XPC” C++ wrappers in your plugin, please go get the new headers!
I’ve written about this before on the X-Plane dev email list, but the short of it is that ‘long’ as a datatype is not safe for plugin use. A long is 64-bits on Mac/Linux but 32-bits on Windows. If you use long, your data structures change size, which is never what you want.
The SDK widget APIs sometimes store widget IDs (which are pointers) in integer slots. in order for this to work, the slots must be 64 bits wide. The old SDK (and XPC wrappers) use ‘long’ for this, but the correct type is intptr_t. The SDK made this change a while ago, the XPC wrappers made this change now, and you should be sure that your plugin isn’t using “long” with the SDK.
The failure mode of mixing ‘long’ and ptrs on Windows is exciting: the upper 32 bits of the address of the widget get cut off; as long as you allocate your widgets early, your widget address is probably less than 2^32, and you are okay. But if your plugin loads later, your widget IDs (which are secretly ptrs to structs) will be > 2^32 and converting them to long changes the address, crashing the sim.
This is exactly why Gizmo appeared to be “crashing” XSquawkBox: XSquawkBox was using ‘long’; if Gizmo ran first and allocated memory (which Gizmo is well within its rights to do!) then XSquawkBox’s widget IDs would be greater than 2^32 and the ‘long’ bug would kick in.
(I don’t know when Wade will release an updated XSquawkBox, and I do not plan to discuss XSquawkBox any more on this blog. You can follow XSB here.)
Whose Bug Is It Anyway?
The XSquawkBox + Gizmo crash illustrates an important point: if two add-ons work by themselves but crash when used together, we can’t know which add-on is at fault without more investigation.
In this case, the bug was in XSquawkBox. But before I investigated on my computer, Ben Russell reported to me that removing some initialization code from Gizmo also “fixed” the problem (in that it made the symptoms disappear). Yet we know from investigation in the code that XSquawkBox had the bug (using long for pointers on Windows).
The moral of the story is: if two add-ons crash together, we can’t know which add-on is fault by which add-on changes to “fix” the problem. It is very common in the OpenGL world for the driver team to change the driver to work around buggy apps, and for apps to work around problems in buggy drivers. A change to code might be a fix for a bug, but it might be a work-around, avoiding a bug that still exists.
Here’s my take-away point: identifying a conflict between two programs is a way to narrow down a bug, but it is not a fix. We (Laminar Research) almost always ask you to remove add-ons when you see a crash. This is not a fix! We want you to remove add-ons to identify the conflict between X-Plane and a particular add-on (or between two add-ons). The next step is for us to figure out why the add-on might crash X-Plane or vice versa. Typically we prefer to contact the add-on maker directly to get technical information. What we are looking for is an identified conflict with the minimum number of variables.
We’re on release candidate three of WorldEditor 1.2.1. RC3 fixed export of 970 airport files to include frequencies and fixed a bug where you could end up with a two-point hole in a polygon (which would then cause the airport to fail validation).
Hopefully this is the last RC and we can call WED 1.2.1 done shortly.
Huge thanks to Wade for getting the beta going, and to Christian for writing brand new Mac audio support!
Besides being big news for VATSIM users (who were stuck in 32-bit land from now on), 64-bit support is a great fit for XSB because it uses a lot of memory for CSLs, and thus was never very happy as a 32-bit plugin.
This announcement is just that; an announcement. XSquawkBox is not a Laminar Research product. Please do not report bugs to us (Laminar Research). Thanks!
Update: Wade says that this build is time-limited. This is the first public build; he’ll release a time-unlimited build once he’s sure he has the bugs out. So think of this as a public beta.
X-Plane 10.25 beta 3 is now available. If you already have 10.25b1 you will be prompted to auto-update. This build adds some new dry-climate urban textures; here is a comparison.
10.22
10.25b2 with dry urban
If we don’t find any more show-stopping bugs, there will be one release candidate, with some updated level-of-detail distance internal settings.
In the future, I will try to write up the scope of changes for the beta-run when the first beta comes out, so you don’t have to ask “will you fix X in this beta?” For small betas, we try to have all intended fixes available in beta 1, but sometimes (such as with dry urban textures) the fixes go into later betas because they are not ready).
