EXPERIMENTAL USE ONLY!!! -- [What?] -- Login to add public annotations [How? >>YouTube].

X-Plane 10.32r1 is now available to beta test – to get it, run the updater and click “get new betas”.  Release notes here.

10.32r1 is another small patch aimed at fixing critical bugs. Hopefully soon (E.g. in a week or two) we’ll start a beta of X-Plane 10.35, which will contain new airports from the X-Plane Airport Gateway, as well as smaller feature enhancements that people have asked for.

Right now it looks like fixes for Yosemite will go into X-Plane 10.35 and improved DSF loading and longer DSF visibility will go into X-Plane 10.40 if the code is solid enough.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

63 comments on “Try X-Plane 10.32r1”

  1. Kudos to Philipp for great release notes. Pleased to see the datarefs.txt enhancements!

    Thanks for sharing when we’ll see the extended DSF range usage, Ben. 😉

    3. Here’s what I will say about changes to fog and visibility:

      I’m not going to comment further on them or post pictures until at least 10.40 because this stuff isn’t going in until at least 10.40, and I literally haven’t looked at it since before 10.30.

      The code is sitting on a GIT branch waiting for me to pick it back up again. Before I put it down alpilotx did run with the code and it seemed to mostly work, so that was good.

      The branch with vis changes includes changes to the fog algorithm (at least to reduce artifacts), better threaded DSF loading and optionally 12 DSFs. So it’s complicated enough that it needs to go into a major patch.

  4. 10.35 for simulated instencing? To hardware instencing . Anyway good news but did you rest? 😉

  5. If I already have several of the airports installed on my computer (downloaded from the gateway), what happens when I get the latest version of X-Plane? Does it replace the folder in my customer airports folder? Or will it just ignore those folders and use the airports that come with X-Plane since they are (I assume) newer?

    I’d test myself but I have the Steam version so I can’t really beta…that I’m aware of…

    1. Neither – custom airports you have installed will override what we install. So you have one-off installed gateway airports, you should probably remove them when we update the global airports.

      1. Are all the airports that are in the database at the point you cut 10.32rc* going to be everything that is in the database (well, that’s been okayed for release)?

        1. Um, that doesn’t quite make sense to me.

          – There was a cutoff for the most recent collection of airports – I think it was, like, a few days ago.
          – Those airports are going into _1035_, not _1032_.
          – No new airports are going into 1032.

          Anyway, if your airport didn’t make cutoff, please don’t panic or freak out. Our goal is to -increase the frequency- of airport releases, and as we get through a few airport updates, I think it will go faster. We can turn a sim patch in days, not weeks, and airports will get that way too.

          1. Ah, sorry, I wasn’t trying to be confusing, I just confused myself ;). I thought the airports were in 10.32, but rather they are going to be in 10.35. And it sounds like you guys are getting all the airports I downloaded a couple days ago so…no complaints here.

            As for my own created airports…I’ll just leave those in the scenery folder as they are “under development” anyway.

  6. Yeah!! The “Lycoming-friendly” cranking procedure! I’ve been waiting for it so long!
    Thank you guys, keep up the great work!

      1. Oh, I appreciate it tremendously!! As a real pilot I never had the chance to fly fuel-injected, Continental-powered aircrafts (whose startup procedure can be already simulated pretty well in X-P)… Only Lycoming so far. So I was pretty frustrated for being unable to do at home what I used to do in the real thing. At last I can!

      2. Anything that improves the realism of piston engines in the simulator is a big plus in my book.

        Me three! ;oD

  7. Well, since we may have to wait till 10.40 for Visibility……. can we at least have some more screens of it? 😀 still dreaming…… also was the increase of the planet render resolution to the v7 level going to be part of that release or is it still on the fence? It would really a game changer for me!

    1. The increase in the planet render resolution will be less important when we can load more DSF’s, thus pushing back the colored mud. But when you really get up there, the difference will now seem even more stark. So… +1 to the higher rez planet, Ben!

      Also – I understand not posting more screenies of the enhanced visibility range. But I really, really appreciate taking the time to say something definitive. 🙂

  8. Excellent, finally a new blog post 🙂

    Any possibilites on letting us in on what you guys are working on for 10.40, besides the DSF visibility?

  9. Awesome, just when I finished my apt.dat to Airport.txt converter script you start include the data out of the box! 😉

    But I guess I would still need this for custom airports that are not in the x-plane database? If I want those customs to be navigate-able by the 430/530

    Thank you.

      2. Any chance stock,and custom seaports can be added so they work also with the new GPS’s?

  10. A well known bug/bad implementation is the blocky shadows i do not understand why not more people are asking for this to be fixed is beyond my understanding. This bug in the visual aspect should be one of the first priorities , it damages the whole visual aspect and reminds me “games” from the past decade, or should i say two decades , is that so hard to get fixed ?

    Don’t get me wrong i love x-plane but why on earth on 2015 we have to deal with these blocky shadows…. (did i made myself clear… that this bug is so annoying ? )

    2. John, it actually depends on the technique used to implement shadowing in the rendering engine. If X-Plane, as I suppose, uses cascaded shadow mapping or similar techniques, then the blocky appearance in some situations is unavoidable and part of the limitations of this technique. As such, it obviously can’t be classified as “bug”. Other Sims, without mentioning them here, have to deal with this very same problem. We all would like to have super beautiful shadows but we currently must live with limited computing resources…

      1. X-Plane -does- use cascading shadow maps. In fact, the cascades are set up in settings.txt and you can just change them. 🙂

        I have a todo item to try to tune them better; my current theory is that a smaller number of larger shadow maps would be a win. This is normally opposite of the logic of CSM but in X-Plane’s case we pick up a lot of CPU cost per cascade because the close cascades are often smaller than our chunk size for single scenery draw calls. So…by using fewer, larger CSMs users could potentially go up a CSM level without fps going way down. It’s also possible to simply crank the VRAM in the settings or decrease the shadow casting distance.

        (The fundamental problem is distance – shooters can often get away with 1 km of shadows or less….that’s too short of a distance for flight simulator.)

        The -major- issue with shadows is this: in the case where we are looking down at the ground from nearby, if we can know the distance of the ground from the camera, the shadows can be retuned for optimal resolution. But X-Plane does -not- currently have a way of finding this out, so when you look straight down at your airplane with shadows, the shadows become more blocky. In this case what’s happening is the shadow resolution is being wasted in the air above the ground and the area below the ground. The tuning of CSM is not at all trivial.

  11. Hi Ben

    Now when talking of new features in next big patch..
    What happened to Hardware tessellation ? is this in XP now.. Know there was talk of this way back…

    regards
    Henrik

    1. Hardware Tessellation is still on our road map, but it is not a short term feature, and never has been. We are incrementally modifying our scenery tech and engine so that we will be able to take advantage of it someday.

    1. Philipp is working now on ATC bugs. I don’t know how fast bug fixes will get in, but there are -already- ATC fixes in 10.32r1. Philipp’s goal is to make the existing ATC functionality stable, not buggy, and usable.

  13. “Several improvements in ADSB-output for apps like X-Avion, Foreflight, FlyQ, WingX Pro, etc..”

    Any chance that someone could elaborate on the improvements? Two of the biggest items for me are for Foreflight to have the ability to pull data from XP as FlyQ does with weather and Traffic. Foreflight has told me “that it is just a matter of XP making adjustments to their code.” So of course I am wondering if this has been done and if so, is there something on my end that I need to do to make it work. Thanks guys for the great work.

    Chris

  14. Hi Ben

    First, thanks for a great flight simulator! I really love it.

    Is there any new work being done on utilizing more cpu cores? It’s frustrating to see the quad core CPU cranking at 25%, the GPU at 50%, all because the main thread is busy 100% 🙁

    I know you have explained stuff with core usage in X-Plane in the past, but maybe another blog post would be cool with the state in XP10 and what we might expect in the future? 🙂

    Michel

    1. With every change to the sim, we try to distribute work across more cores.

      But when you’re sitting on the runway, we’re not going to max out all 4 cores. If we did, then there’d be no CPU resources left to load scenery while you fly.

      If you are on Windows and you are not using plugins that screw it up, the AMD and NVidia drivers will run mostly in a second thread, giving greater than one core use for X-Plane. So in the case where you have four cores, we might have one for the driver, one for X-Plane’s rendering, one loading a DSF, and one building autogen…adding more rendering work to a core may mean fps drops while scenery pages in.

      (I am still trying to spread out the work more evenly, but understand that there’s no free lunch here. In the old days of 1 core when the sim did a load, you felt it; if we max out the ENTIRE CPU it’s going to be like that again.)

      1. Hi Ben

        Yes, I do understand the trade-offs and drawbacks. But even while flying around I’m not seeing anything >30% for most of the time, with some spikes (to like 50%) (probably scenery loading).

        The CPU is already some years old (i7 860), so I guess you could actually load them more without getting the drawbacks of “the old times” back.

        Also, if that *would* be the case, wouldn’t people just need to dial back their CPU-affecting rendering options?

        I will also try to disable all plugins and see if that improves the state of things 🙂

      2. Acknowledging that this may be slightly off topic from the original beta announcement…. besides the fact that the answer could probably could fill another post entirely…

        How many threads will an out-of-box install of xplane start up? Does this differ between the 3 supported OSs? Are plugins ever farmed out to separate threads (do they even need to be?)?

        If I’ve understood past posts correctly, it seems as though the biggest FPS bottleneck is that only 1 thread can talk to the GPU. Is it possible to load that thread up to the point that it dominates 1 core? If so (and if that even makes sense from a computer science perspective), how close is the current build to that status?

        1. We start a worker for all but one cores, so that with the main thread the farm can drive the entire machine.

          We also start background threads that are almost entirely asleep for Quicktime movie saving (on platforms that support it) and Garmin hardware support, but both are basically blocked most of the time. Async HTTP (e.g. calling up the server to check for updates) currently launches an IO bound thread in 1030.

          A few threads get launched on our behalf by the OS/driver:

          – There’s a sound mixing thread on OS X – probably the other OSes have that too.
          – The Windows GPU drivers almost always launch one driver worker thread per each of our threads so that the can push out GPU driver work
          to another thread.

          Because of these we could technically be over-subscribed; however as you can guess from the posts here, we are usually not. 🙂

          Plugins never go to threads – the API is main thread only; plugins can start their own workers if they need.

          In terms of main thread rendering: the main thread currently divides its time between rendering, the flight model for the user’s plane (other planes can go to worker threads) and plugins. If plugins aren’t chewing up a lot of CPU, rendering will often take 90-95% of that core. So I’d say that rendering dominates the 1 core it gets now. (For this reason, I often suggest a faster clocked i5 over a slower-clocked i7.)

          In an ideal rendering situation on Windows, no one is screwing up the threading of the GPU driver’s worker thread, and we might see 1.5 – cores worth of rendering work being done.

          cheers
          ben

          1. Thank you for the peek under the hood. Very surprised to see the flight model taking up so little. Time to thrown in some boundary layer modeling, maybe??

            Somewhat depressingly, I can confirm the clock speed impact. Just helped a friend build a i7 5960x/GTX980 monster. At my own i7 4770/GTX770 rendering options (I know, I know, not a proper scientific study) I was 5-10 fps higher while sitting on the same runway. Not bad for a 500mhz delta in base clock. And then of course we cranked up the sliders on both and the 980 took over… Besides, nobody really needs 60 fps! *blog fire alarm sounds*

            UBO? Smells like GL3.x…. Wish I knew more on that side of things. I must say, the xplane parallel world appears much more entertaining than mine, waiting for those f90 MPI_Waits to finish up on the cluster.

          2. As we’ve had more CPU power over the last few versions, we’ve found ways to use it to do more visually. In the case of the flight model, there isn’t a next level that will add a ton of realism but at the cost of a ton of CPU.

            (Note that the AI planes run in parallel on multiple cores..when you run _20_ AI planes, they would monopolize the CPU. But when you run 20 AI planes the physics spread to multiple cores and the graphics pile up on the main core, so again the physics isn’t the bottleneck.)

            Within the FM the most expensive thing is collision checking with the scenery engine – again, it’s that scenery scaling up in detail.

      3. And by “load that thread up…” I meant isolate and load up that one process (talking to the GPU) such that it dominates a single core.

        1. Ah – to get better frame rate than what we can get through one core we would need to divide the rendering load on our side to be multi-core for that single task — not trivial!

          My view is that a better way to get better fps is just to make the whole engine faster – it helps people who don’t have extra cores too, and frankly it’s probably easier to optimize the engine than to split rendering across two cores (when the driver is -already- moving driver work to another core). So I’m a lot more interested in using UBOs (constant buffers) than in pipelining our rendering code.

          (There are other long term uses of those other cores that I do want to look at.)

          1. While optimizing the engine is certainly a good thing to do, it will not bring you to a new performance level. Computers will get more cores, not higher CPU clock, period. With 4-cores being the norm nowadays (they will take over more in Broadwell and Skywell for mobile platforms as well), and 6 to 8 cores being adopted now.

            I predict that this issue will be annoyance number one pretty soon 🙂

            It seems that you are running a functional division model for your threads (i.e. splitting by subsystem like sound, rendering, AI).

            Intel suggests to instead use a “Task”-based model, to further sub-divide these functional areas into smaller tasks. It is certainly an interesting topic 🙂
            Here some Intel Videos for interested parties (I’m a programmer…): Don’t Dread Threads Part 1
            Don’t Dread Threads Part 2
            Don’t Dread Threads Part 3
            Task-based Multithreading – How to Program for 100 cores

          2. We’re not as functionally threaded as it sounds; the poster wanted a thread list, so it comes off that way, but a lot of threaded activity just goes to the pool as “tasks”:
            – DSF loading and DSF 3-d “stuff” instantiation.
            – Texturing Loading.
            – Flight model evaluation.
            – Scenery tile maintenance and car driving.

            Most of the functional threads we have are IO blocked threads like the Garmin hardware thread and the HTTP network thread.

            The only heavy work we do on a functional thread is QuickTime movie capture, and the replacement for QuickTime will do its CPU work in the task pool.

  16. In the Relesae notes for XP10.32(beta) it says:
    “Added airports from the X-Plane airport scenery database to the new GPS – this allows for selection of small and grass airfields that have no instrument procedures”.
    Does that mean you have added an updated couple of files:
    Airports.txt and Waypoints.txt both Date modified: 03/01/2015 14:05
    But the header still says:
    X,1405,01MAY28MAY/14,1404,03APR30APR/14 and

    In X-Plane 10\Resources\GNS430\navdata, Which is great, but!!

    But that mean as soon as the user tries to “update” using Aerosoft or Navigraph that they will “loose the use” of those files added in your XP10.32(beta) because Aerosoft & Navigraph’s installers will install in Custom Data. And XP uses X-Plane 10\Custom Data before X-Plane 10\Resources? So it won’t see the files you added any more?

    1. No, it does not require any file to be changed, neither in Resources/GNS430/navdata nor in Custom Data/ – no information was added to these files by us, nor will data providers need to put more data in their files.
      Instead, X-Plane looks at ALL airports it knows from scenery, that is global scenery, gateway airports and custom scenery airports, and matches up the airports with those from the Airport.txt (GPS database). It then adds the airports being present in the scenery, but not in the GPS data, to the _internal_ memory of the GPS, without touching any of the _external_ files.
      That means it’ll do that no matter if you use data updates from Navigraph, Aerosoft, or none at all.

      1. Phillip said: “That means it’ll do that no matter if you use data updates from Navigraph, Aerosoft, or none at all.”

        That’s very clever Philipp. 🙂

          1. Displaying heliports or seaplane bases by default would be VERY DANGEROUS. Imagine you are flying along in the C172 which does neither have a main rotor nor floats. The engine quits and in the knee-jerk reaction you twist the right knob fully to the right, to get to the nearest page, and select the topmost airport from the list. While you are happily gliding down your way to the “nearest airport” you’d be very surprised to find yourself headed for a pond, or what would be even worse, the rooftop of a hospital.

            The real G430/530 have special variants for helicopters with a different database that include heliports along with HTAWS, and the certification for that was added rather late in the G430 lifecycle. No special variant that I know of exists for seaplanes, though seaplane pilots might know more about that.

            I could possibly add a setting for PlaneMaker that allows you to get a helicopter- or seaplane-friendly version of the GNS. But it doesn’t make sense to dump it into the standard database without asking questions.

          2. I wasn’t suggesting “Displaying ALL heliports or seaplane bases by default “, just that it is a shame you can’t enter say a heliport as a “Origin” or “destination”, so your idea of a option for a helicopter [H] – or seaplane [S] -friendly version of the GNS would make a lot of users very happy!
            Maybe a [H] or [S] on the NRST page?
            Great idea!! 🙂

          3. I’ll second that….There really should be someway to have it usefull for seaports and helipads.

          4. The setting we are all looking for already exists!
            In Plane-Maker, there’s the following checkbox:
            “only airports on map| If your moving map does not show helipads and seaports, then check that here.”
            With the next version, we will simply adhere to the value of this checkbox. Of course, whether all designers of fixed wing land aircraft did indeed check that PlaneMaker box is another story, but at least the new GPS will then be consistent with the rest of the X-Plane instruments.

  17. Phillip have you had any time to explore oculus rift support any further? Is it something we may see in 10.40 even in beta form?

Comments are closed.