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.
RT @XPlaneOfficial: Dev Blog Post: A Release Candidate, a New SDK, and Incompatibility http://t.co/5Q2hKl9YGx #xplane
Hey,
Thanks for update!
I saw some screenshots and videos about the upcoming P3D V2,which really made me think that some stuff in XP10 needs to be fixed,so i have some questions:
1) Fog and visibility,XP10 visibility above of 10 miles is almost infinite,and the transition between the fog & cloud “layers” is rreally abrupt,are thoose gonna be things that well be fixed in 10.30?
about the fog and clouds,SkyMaxxPro has some optimizations for this I think but it still to be fixed I think.
2) As for OpenGL,is the “rumor” that you are gonna make XP10 take advantage on newer OpenGL version in 10.30 is true?
3) And that’s a question for farther future actually,will ever XP10 take advantage on SLI/CF?
Hi Gal,
1. I cannot comment on the feature list of 10.30 – it isn’t decided or finalized, and I wouldn’t pre-announce it before beta even it was. I can say that we have ideas on how to make the fog and visibility situation look better in x-plane, and we want to get them into a build, but they are also too invasive to go into 10.25.
2. Using more modern OpenGL is an on-going process, and at least some of this work is already finished in our ‘latest’ code. I expect that some of this will ship in 10.30. I do not think the process will be complete for 10.30.
But also, as a user, do you care? I think what you can actually measure and care about is real performance and quality changes. (I mean, if you are just curious, then great – I’m a big geek and care about these things, but I worry that users get too obsessed on the buzz words and not enough on the actual results.)
3. I am under the impression that X-Plane 10 can probably take advantage of them now _if_ you build a profile to enable AFR yourself. But I do not have CF or SLI machines myself, and thus I have never tried it.
I still advise one big GPU over two small ones if the price is comparable – when you have dual GPUs you don’t get the sum of the VRAM of both in SLI or CF mode.
Cheers
Ben
Thanks Ben,looking forward to all of this,sound great 🙂
You should ask Laminar to buy you a SLI machine ! A lot of PC gamers are using SLI rigs. Just saying.
Having experience with both CF and SLI over the years, I have come to the conclusion they really aren’t worth the hassle [for me]. The scaling isn’t as linear as I would like and often the drivers have too many quirks.
These days, I’ll take a beastly single GPU for gaming. No headaches.
That said, I have built 4 machines with 4 Titans each for my son’s network to do GPU rendering of architectural CAD drawings and videos using OctaneRender. Perfect scaling BTW…
+1 for the Fog Fix 🙂
As you are tweaking autogen ans textures…is it possible to have the GPU randomize texture colours within a certain spectrum? Tree textures, buildings and some ground textures would probably appear much more realistic and the whole scenery more vivid with some “colour play”. Any thought on letting the autogen lights “fade in” rather than pop up in the distance? Even with high world distance setting this is very obvious at night.
Regards
Flo
Yep – in fact the autogen already does this! You might not notice it because the effect is very subtle. (We only do a monochromatic change though, not full color.)