X-Plane 10.10r1, Screen-Casts, and Airplanes

16 comments on “X-Plane 10.10r1, Screen-Casts, and Airplanes”

1. Very useful format IMO. Thanks.

2. Nicely done, even overdone, I’d say. Very useful for the youtube generation; less so for impatient older folk like me who can devour the print equivalent in less than 5 minutes (some wikis excepted).

   Nice too to see the starter get some attention. Similar attention devoted to SFC, the effects of critical altitude settings, and the fadec would be very welcome indeed. I’m about to toss the latter and go heads down for a week or two because the torque and rpm monkeys are AWOL. Oh, not to mention those Expert Options: custom gear settings, custom autopilot settings (gone from XP10 docs, I think), etc.

   BTW, I can’t recall ever seeing such a bare dock on a Mac.

3. And just when i knew it all, you teach me something new. The video was fantastic, and i actually now have a better understanding of how the starters work. Please yes, do more of these in the future.

4. “10.10 is not particularly happy with current ATI drivers” ?! X-Plane is now more than 9months old and I spent 70.-EUR on you guys quite in the beginning believing that you would produce a usable flight simulator. Last time you spoke about problems with ATI (March or April?), you promised you would be working hard to get the problems ironed out and now, half a year later you’re telling us that “x-plane is not particularly happy” with ATI and you want to deactivate features when detecting ATI equipment ??? Are you joking ? It makes me sick that I trusted in you guys and gave you my money so early believing you would deliver what you promised. Lesson learned – deinstalling x-plane now for once and for ever. Bye.

   1. Hi Alberto,

      The feature with ATI cards that is not working correctly is sRGB blending. Turning off the use of this feature makes X-Plane work fine. This kind of thing happens all the time with games and graphic drivers; the drivers expose a huge number of APIs and sometimes they have bugs when used in a particular way, and sometimes the game developers simply stop using a particular driver feature and code an alternate implementation themselves, rather than wait for a driver fix.

      The most likely situation is that we will (1) program X-Plane to automatically to disable sRGB blending in response to certain ATI drivers and (2) program X-Plane to re-enable it when ATI is able to fix the problem – all completely transparent to the user. You would not lose any aspect of the sim (e.g. we’re not turnign off ATC to removing an airplane), we’re just rendering without GL_EXT_framebuffer_srgb until it works right.

      Here’s another example; we discovered in 10.10r1 that glDepthRange doesn’t work on OS X with nvidia drivers if the near and far values equal. It works on OS X Mac drivers, Windows nvidia drivers, and windows ATI drivers. So we replace this call to glDepthRange with an equal range with a change to one of the transform matrices – another API – exactly the same result with exactly the same performance. Problem solved. Work-arounds for driver problems happen _all the time_.

      So: we are working around a driver bug and you decide you want to throw out the forever??? Are you joking? It makes me sick that I trusted in you to tell you exactly what we were working on, believing that you would react rationally to standard gaming industry practices. Lesson learned – next time we have a driver bug, we’ll just silently work around the feature and not say anything. Bye.

      1. Well I appreciate you being open with those issues. Even telling him off now 🙂 I think most users appreciate you being open on this. Pls keep this up and ignore those few complaining.

         1. Well, I can appreciate why Albert expects the sim to work well — and this is why we put so much effort into making sure that the sim works on all cards, no matter what the driver situation. This is also why we intend to come up with an acceptable solution before we finalize 10.10.

      2. Would disabling sRGB have any impact other than calibration issues on calibrated gear?

         1. It changes the color fall off curve of the runway lights. We think with sRGB is better – otherwise we wouldn’t use it, but the sim is still quite functional without it. Run with –no_srgb and observe the runway lights. 🙂

            1. I haven’t yet got around to actually look at the difference, but from reading the documentaion, the major change is that the entire framebuffer is using non-linear sRGB, and every blend operation requires two conversions (to linear for blending, and then back to sRGB) of every affected fragment.

               Effectively, the difference appears to be due to the nonlinearity of the entire framebuffer, which of course would be most obvious on high-contrast elements like runway lights where falloff occurs in a rather narrow “halo”.

               With that complexity in mind, would it not make more sense to have the shader for such point lights take care of that nonlinearity?

            2. You can do the transform in shader but you can’t _blend_ in shader…that’s why we use sRGB – in some cases the color transform is in shader. (If you can get the dedicated hw to do it, you also save ALU.)

      3. Thanks for your detailed explanation of the problem.
         In your original blog post this sounds very different – if I may quote you: “We may have to disable functionality when we identify this driver set”. Disable functionality !! That sounds quite different, doesn’t it ?
         You could have left it at clearing up the missunderstanding you caused by talking about “disabling functionality” instead of “changing the color falloff of runway lights”. But you decided to take the mickey out of me with your last paragraph, which leaves a bitter taste when I think in which state this overpriced piece of software still is in nine months after it’s release.
         Ah forget it, I’m out of here.

         1. Hi Alberto,

            I can’t deny my last paragraph was snarky and rude, and for that I apologize. But having spent the number of hours I have spent going through hell to make ATI cards perform as good as possible only to read that I have failed to deliver what I promise because ATI cards put out crazy colors when sRGB is enabled (something I really can’t fix), what can I say – your comment really frustrated me.

            But I do think the _intent_ of my original post was correct even if the way I said it was rude. The intent was this: none of us should react too severely about these things. Fixing driver issues takes time, the beta isn’t final, ATI will issue new drivers, so wait and see before you throw the sim out, because we really are trying to make it as good as possible.

            But in the end the choice is yours; if you think that the value proposition of X-Plane is not there, that is your opinion and not something for me to argue with.

5. Love the line about METAR data (hopefully) not creating insane roller-coaster flying anymore. That seems to be an item many people will cheer about, judging from the range of discussions I found.

6. Did alberto confuse this ATI-driver bug with the ATI-percormance bug, maybe? I still have to turn down clouds (and shadows, and reflections) to minimum with a 6850, though. And about the METAR: will there be “transitions” between weather changes? Because sometimes the abrupt changes even damage the plane in flight.

   1. The ATI performance bug isn’t really a bug, it’s just not fast. On 10.10r1 if you have to turn down clouds, it’s because you’re out of fill rate. On 10.05r1 we don’t use the fastest driver path.

Comments are closed.