All i know is XPlane is all about as close to authentic flight model as possible, ye love to see more trees, better clouds, but with Vulcan now im really enjoying it with TrakIR, specially now i have a decent machine. Still spend more time making airports than flying off to finish YBHI. CAn we have some more ga and regional planes, enough with the Jets.

9 hours ago, mSparks said:

I take a little bit of offense to that.

A little bit is ok 😉

After all they pinned a post just because of you:

🤣😂

Edited November 1, 20205 yr by Janov

5 hours ago, Janov said:

just because of you:

Surely it needed pinning because of and for the people who took it as a personal insult that all the aircraft manufacturers chose the likes of Lynx RTOS for their aircraft systems

Rather than me and my low expectations of Microsoft trying to emulate those systems in javascript on windows.

Edited November 1, 20205 yr by mSparks

Interesting read about the Lynx RTOS, never heard it before. Fully agree on Java Script. Java Script is 5 to 10 times slower than C++, Python is 10 to 20 times slower than C++, assembler language is faster than C++. Why do chipmakers develop new processors, if the preferred programming languages of todays society makes the processor 10 times slower in average. 10!.

 

Seriously, Java Script for the interfaces of the cockpits. A code that needs to be compiled at run-time and is only meant to be run on Windows. Those two thing just don`t fit together.

Just as Microsoft of today:

Write beautiful code - nothing else matters

Speed, what? I really hope and think X-Plane has a better code, fully optimized for performance.

4 hours ago, BigDee said:

todays society makes the processor 10 times slower in average.

its not all about "frame" speed, there are numerous other factors, like error handling, how much the language can do automatically for you (like managing huge volumes of memory), how easy/cheap it is to develop for (see the OP for more detail on the consequences for many X-Planes....).

"real time" probably doesn't even mean what you think it means, its all about guarantees of meeting deadlines rather than how quickly it can meat a deadline. (a system that never runs less than 30fps can be considered realtime, a windows system that runs at 60fps most of the time is not)

4 hours ago, BigDee said:

Interesting read about the Lynx RTOS, never heard it before.

Generally the good stuff doesn't need to advertise to do well, people who need it search for it. I actually treat most advertising as a warning that real people aren't recommending what's being advertised.

The realtime aspect is also one of those practical aspects that separate simulator from game. Not meeting the deadline is a fatal error state in an RTS, in X-Plane this is why you get the "<20fps not realtime" error message (and Laminar are limited to not doing a proper job of this because windows does not provide any realtime guarantees, so its a best effort + warning).

@Janov could probably do a good job of incorrecting me, he's got first hand experience pressing the actual buttons.

 

Edited November 1, 20205 yr by mSparks

On 10/31/2020 at 5:25 PM, RXP said:

It just takes some know-how to look into the XP11 code and realize they are really carrying a lot of technical debt and legacy code.

Sidney claimed that he and Ben basically rewrote the entire rendering engine for Vulkan, getting rid of some legacy baggage, as proven by OpenGL mode getting a slight performance boost compared to 11.41. Another claim was that OpenGL and Vulkan modes were implemented to their respective specifications, leaving drivers, OS overhead and hardware as the biggest performance-defining factor.

 

@Bjoern my comment was not limited to the rendering engine in particular but to X-Plane.exe as a whole. Nevertheless thank you for the additional precision! I didn't catch their work on Vulkan was improving the OGL part of the simulator as well (as a side-effect of cleaning up). I've just noted they wanted to ensure portability of legacy plugin code in building a "bridge" talking OGL on one side to plugins but running Vulkan on the other side (it is over simplified but I'm trying to illustrate).

Edited November 1, 20205 yr by RXP

22 hours ago, RXP said:

I've just noted they wanted to ensure portability of legacy plugin code in building a "bridge" talking OGL on one side to plugins but running Vulkan on the other side (it is over simplified but I'm trying to illustrate).

Yes and no. The bridge is perfect for implementing "one size fits all" plugin code, but the prime motivation was that there was simply no time to extend the SDK with a separate Vulkan API. If such an API could have been implemented in time for 11.50, Laminar certainly would have delivered it. As far as Sidney told me, capability for drawing plugin code directly in Vulkan is going to become available during XP12's life cycle. Until then, it's all OpenGL calls and entirely the add-on dev's responsibility to keep their plugin from choking the sim (see this thread's subject).

That bridge was a prime headache for me as a Linux AMD user because any drawing OpenGL plugin would crash the simulator. That's why I've asked Sid about drawing directly in Vulkan as an alternative, but the answer was the aforementioned "Maybe in XP12". Note that the crash wasn't XP's fault, but the driver's. It took a bug report and several weeks of back and forth with a developer until it got fixed.

Edited November 2, 20205 yr by Bjoern