One of the new things in X-Plane 10.40: more modern OpenGL code. I mention this because that new code will probably create chaos during the early betas; we’ll get the bugs fixed as quick as we can.
The problem is that OpenGL can be an exercise in “code it once, debug it everywhere”, and while I have tried to set myself up with a wide range of hardware, I don’t have one of every combination of drivers and GPUs that X-Plane runs on.
X-Plane 10.40 will be a longer beta, like 10.30 was, so we should have enough time to work out the kinks in the new code. Having to do this kind of debugging during beta is annoying for everyone, but it’s also necessary to advance the sim forward.
When 10.40 comes out, if the beta doesn’t run on your hardware, please do report a bug; often users assume that if they see the bug then everyone does, so someone else will report it. Not only is this often wrong (because everyone assumes someone else will report a bug), but it might be that your combination of hardware and drivers is the only one that shows the bug!
Update: yesterday at the 2015 WWDC Keynote, Apple announced that they were porting Metal, their Apple-specific low level high performance 3-d API, from iOS to OS X. I will comment on this next week, after the WWDC sessions on the desktop version of Metal are available on the web. In the meantime, don’t panic – this definitely isn’t the end of the Mac, Windows, X-Plane, or the universe.
Just looked at the Beta-X-Plane page and I start to wonder on the production line.
Are you guys working on X-Plane 11 along all betas and update for the current version.
Reason for asking is that sooner or later I take it will see a new version with lots of excellent new ideas and genius inventions that will gob-smack everyone, well I ramble my wishes but regardless a new version would come sooner or later right. As we now there is not that many update numbers left on 10.xx series?
What are your thoughts on this, if any Ben?
Future versions with numbers greater than ten is not something I can blog about.
That is OK Ben, understandable of course..
WILCO
Hi Ben, is there a built in bug reporting tool?
Like when an Android app crashes and let’s you automatically report the crash, along with the relevant log files, etc.
If not then it would be a great addition, even if only included in the betas.
Not for bugs – just for crash reports.
two comments by the price of one is possible 🙂
-is winds aloft still coming on 10.40? i have tested it when Austin released a beta and it was great.
-what is the purpose of the modern OpenGL code? support new features? compatibility? performance? you didn’t put any word about that.
1. yes. generally, everything in the alpha builds that Austin tested are in 1040 beta 1 – the purpose of those tests was to iron out that side of the code.
2. future new features -and- future improved performance!
Bear with me as I’ve missed the list of alpha buils changes, but has anything be done about two crucial points:
1) Easier mesh editing (I think this is really crucial for high quality scenery development) for example months ago you talked about underway at airport…I’ve been spending weeks to create a church complex over an hill and then when I moved to HD mesh I realized heights were screwed up: if we had an easy way to define small area mesh in custom scenery we would be in heaven.
2) Particle system: I think it’s still unconfortable to set contrails or low level vapour trails for aircraft or to depict decent landing effects like tyre smoke/rain puffs.
Thanx
Great news Ben, thanks for the update.
Can you elaborate a bit on the “more modern OpenGL code”? What will these “new things” improve (if any), looking it from the user stand point?
thanks
There should be no user change (good or bad) to -start- with in this build – right now we’re using them in small ways to answer the question: “for what users does this work.” In the long term we’re looking at both improved performance (via more efficient code paths) and improved features (by more powerful OpenGL features).
Hi Ben,
what about the new “Metal” in OS X 11, I saw at the WWDC 2015 today ?
thanks
I’ll have to post separately about this…
yes please! it will be really nice to have your educated comments on this when able. They are claiming huge gains +50% on rendering, +40% efficiency, 10 times draw call performance.
I do not even understand what it -really- means, but sounds like music for mac x-plane guys like myself 🙂
I hope LR will create a fork of X-plane 10 or later that uses Metal and test the stability and performance and after those tests report us users and developers if Metal – “way” is the future for X-plane or not. I know that one of the drawbacks is the cross plattform issue. Theory and practice does not always go hand-in-hand.
I always test performance before/after on any rendering engine change!
Moving to Metal for OSX is like to move to direct-x for windows, you’ll have to manage at least two different situations (what about Linux?) and, speaking for Metal, you must have at least El Capitan so previous OSX versions would be not supported, very hard to imagine a situation like this.
Yep – it has the same problems as DX12: only new hardware, only new OS, only some hardware.
The difference between DX12 and Metal is that Vulkan may provide a -wider- coverage area on the same hardware (new GPUs on Windows).
If Apple were to support Vulkan and Metal we’d probably prefer Vulkan to keep our code unified.
The silver lining is that Metal covers iOS too.
Ben,
Kinda related…Apple talked today about slipping “Metal” over to the Mac platform. As it (supposedly) cuts the overhead pertaining to Open GL, is it something you can leverage into X-Plane?
Thanks!
My guess is no. Metal is not cross platform. In cross platform software, typically, compromises are made to simplify development–the core code has to be applicable to all the platforms involved. LR has a small staff, they can not create parallel versions for all 3 platforms.
Unfortunately, for you and I, this means the Mac suffers. The things a developer does to create cross platform applications tends to run faster on windoze than it does on a Mac. The reason being while Apple supports the other architectures*, it does so just barely—often times being several versions behind; Microsoft does not support Apple’s architecture at all. Each version would probably take more than twice as long (but it would be nice for the Mac version to finally kick ass.)
It will be interesting to see what happens in the Linux world with Swift 2 being Open Source.
* Architecture is actually not the right word, but I think it conveys the meaning more readily than a long technical discussion.
Metal being OS X specific is not -necessarily- a show stopper, although it isn’t as convenient as a truly cross-platform API.
When it comes to cross platform code, the cost is differences in -abstraction level-, not differences in the API itself. So to the extent that Metal is a low level API with DIY threading and explicit command queues, making an engine that runs on top of Metal and Mantle (for example) would not be that difficult; the engine would have the same kinds of operations available on both platforms.
By comparison, making an engine that runs on Metal/Mantle _and_ OpenGL is significantly more difficult, because both Metal and Mantle (and probably DX12 and Vulkan) provide API constructs that OpenGL doesn’t have, or cannot implement efficiently.
Unfortunately what this means for us is that we almost certainly get to do the maximum amount of development work. All of the _new_ graphics APIs require relatively new hardware, so it’s going to be a long time before a program like X-Plane (which runs on a wide range of hardware) can require a new graphics API. We may have to be able to run on OpenGL (for older hardware) and also some new-fangled API (varying by platform) for new hardware to get maximum performance. In that scenario, handling multiple new APIs will not be nearly as painful as handling OpenGL vs the new APIs.
This isn’t unprecedented; X-Plane 9 could run in fixed function or programmable shader mode, and X-Plane 10 runs with forward and deferred rendering.
If you look at the games world, lots of game engines run on multiple underlying host APIs, often on different platforms, and often with very different rendering modes based on the capabilities of the hardware.
As a final note, while the mobile and desktop apps are separate code bases, they are -deeply- related and we try to keep them as unified as possible. So in a weird sense, Metal now -is- a cross-platform API – it’s cross mobile/desktop.
I was wondering if the IOS mobile version use METAL and if it will help to port code from and forth. also swift2 is now open source.
Will that be of any help. I mean (i dont know) it look like a good thing for you. and in return us…
The IOS app uses GLES 2.0, not Metal. We do not use Swift.
Are you planning to add support for Metal, which has been introduced now in OS X 10.11 as well as iOS 8?
When are you planing to release the firt 10.40 beta ?
Cheers…….
Soon as I can get my last few bugs squashed.
Hello Ben. My question is, when the X-Plane 10 will be introduced DirectX and whether you plan to exit DirectX 12 start podderhku X-Plane 10, as well as the second question is whether X-Plane 10.40 support Windows 10 after release.
We are -not- looking at DirectX 12 at all right now, and it is the least likely candidate for a graphics API for X-Plane.
IF the effort to create high quality Vulkan drivers on Windows fails, -then- we will have to look at DirectX 12 and evaluate it relative to OpenGL.
If the effort to create high quality Vulkan drivers on Windows succeeds, it would be better for us. It would:
– Provide the same benefits as DX12.
– Run on Android.
– Run on Linux.
I hate to say this to the Linux nerds, but having a high performance API on Linux isn’t a top priority for us — if we can have working Linux as a side benefit, we’ll take it. But the percentage of our users that run Linux is very small — less than 5% — so we can’t adopt a new graphics API _just_ for Linux.
By comparison, Android support would be way more important. In the long term, we view iOS and Android as our two mobile operating systems, so ideally we’d like a high performance graphics solution on both.
“””But the percentage of our users that run Linux is very small — less than 5% — so we can’t adopt a new graphics API _just_ for Linux.”””
That’s the wrong way of looking at it — it’s about 90% of the Linux flightsim enthusiasts that run X-plane, on Windows it is much less because of FSX and P3D etc! (only slightly tongue in cheek)
I heard about Metal in OS X, but it’s exclusively for Apple platforms, and I’m not too interested. Any news about Vulkan or DX12? Vulkan is cross-platform, and therefore more likely to be adopted by LR for X-Plane…
It’s way too early re: Vulkan…at this point the only thing we know is that it will be Mantle++ and we know some of the design principles. It’s a relief to know those design principles, because they fit well with what we’re trying to do, and it’s also nice to see the mobile GPU vendors involved (because non-IOS mobile graphics is by far the weakest area of 3-d right now in terms of API/driver support; GLES on Android is sort of a disaster). But we’re still very far away from having something to code to.
Well, that’s nice to hear. So you’re saying it all depends on the drivers and how much support MS and all the devs give to Vulkan. Both Apple and MS have now got their own APIs to develop for, that Vulkan seems like an afterthought – everyone is drooling over Metal and DX12. I’d much rather a decent cross-platform API, since I frequently switch operating systems to suit my workflows.
As for mobile device support, all the better – I can flight sim faster and smoother on the go. Here’s hoping Vulkan looks and performs well on all five platforms…
I don’t think MS is going to have a big influence on Vulkan. If I understand the architecture correctly (and I probably don’t – the information so far is very preliminary) it’s going to be an open source loader for a IHV (read: nv, AMD) DLL that talks to the device driver itself.
So what really matters is IHV buy-in. And for what it’s worth, the IHVs need to do this, because in the mobile Android space, there is no next-gen high performance low overhead API. There’s no Google-proprietary thing, and GL doesn’t scale up because it always is anchored by its threading model. So at the SigGraph announcement, to me the interesting thing was that Imagination, ARM and Qualcomm, AMD, Intel and Nvidia were all involved. That’s enough vendors to have “effectively total” coverage on both Windows, Linux and Android – that is, everywhere you can’t get Metal.
Metal? If you intend to leave OpenGL, I would propose Vulkan, as it’s crossplatform.-
I do agree
Hello Ben,
Since 10.40 will be a major update is possible to update de magvar data too?
Instead of Apple’s Metal I’d rather take a look at Vulkan, it’s a real cross-platform API
Even FSX Steam Edition Prepar3D v2.5 and below the level of X-Plane 10.35 and especially the upcoming X-Plane 10.40.
This from Blizzard: “We will support Metal and OpenGL 3.3/4.1 in a future patch after 10.11 ships.
I don’t know which patch yet so that’s all I can say but I would rather it be sooner than later.”