Tyler posted about some of the new features coming to the X-Plane SDK version 3.0 API (available with 11.10 once we find the last bug and move it somewhere else). Here’s how compatibility works for the windowing system.
First, since the 2.0 SDK, XPLMCreateWindowEx has taken all of its arguments in a structure, a XPLMCreateWindow_t. That structure, in turn has a structSize variable that is meant to be initialized like this:
XPLMCreateWindow_t my_win = { 0 }; my_win.structSize = sizeof(my_win); my_win.froblinator = xplmFull_Of_Eels; // etc. XPLMCreateWindowEx(&my_win);
Now when we revise the SDK, the size of the XPLMCreateWindow_t structure grows when you #define XPLM300. This results in new plugins compiled with the new SDK sending in a large struct (with more callbacks) and older plugins compiled against the old SDK sending in a small struct.
This is how the SDK “knows” what SDK you are using and provides new behavior to new plugins but provides compatible behavior to existing plugins, compiled years ago.
(This technique isn’t in any way new or unique to the X-Plane SDK – you can tell by the coding conventions that it is cough, cough, borrowed from the Win32 SDK.)
Okay, I’ll bite: is that a literal “the last bug” and is that referring to a last bug in the 3.0 SDK, or to 11.10 in general? 😀
It was referring to beta-stopping bugs, and we think we fixed it.
Exactly what I meant, thanks. Great news, really looking forward to getting my hands on the new lego brick assets in 11.10 as I have two airfields ready for them.
p.s.: you should get Alex to post on the dev blog too! 😉
Is it possible to build a plugin with SDK version 3.0 and also have it work in X-Plane 10.51r2?
How is the bug removing going?
Thanks Bill
Hi Bill,
Yes – you do that by getting the new SDK and NOT defining XPLM300 to 1 – the SDK then ‘looks’ like the 2.0 SDK to your plugin and provides a binary that X-plane things is 2.0 as well.
We usually keep legacy SDK distributions available for download, e.g. the new SDK can ‘look’ like 3.0, 2.1, 2.0 or 1.0, but it will only generate x86_64 binaries — we don’t have PowerPC DLLs, for example.
Hi Ben,
So if I understand correctly if I want our Xchecklist plugin to use the new features from SDK 3.0 for users with hi-DPI/4k monitors we will need two different plugin versions to support both XP10 & XP11?
Thanks Bill
You _can_ make a plugin _dynamically_ use both APIs but it is significantly more work. You would basically need to:
1. Query at runtime which SDK version you have.
2. Pass different size window init structs that are version appropriate.
3. Call any 3.0 API by using XPLMFindSymbol and _not_ linking directly against it.
It is absolutely possible to create a binary that works this way, but the SDK doesn’t have a one-shot #define that gets it for you. The least bad thing I can think of is:
– For window initialization create two separate CPPs with utility functions (create_window_21, create_window_30) and define XPLM_300 in one of them to get the new window create struct.
– Manually create function ptrs to any new 3.0 APIs you need, again maybe in a separate #define XPLM300 file.
There is also a cheap trick you could do: pack the 2.1 plugin into the old packing (plugin/64/win.xpl) and pack the 3.0 plugin into the new packing (plugin/win_x64/plugin.xpl). The new 3.0 search path is higher priority in 11.10 and newer, and the old search path will make old SDKs work.
You’d then just compile your plugin twice, once with XPLM300 on and once with it off and #define your own code around the new APIs.
Thanks Ben,
The second option looks like it will work quite well for us.
I assume there would also be paths of plugin/lin_x64/plugin.xpl and plugin/mac_x64/plugin.xpl for the other platforms.
Bill