The next X-Plane update will focus primarily on flight-model and systems, plus external-visual networking and some ATC features. While that update is in beta, we can work in parallel on real weather and graphics.

But there are two graphics bugs we already have fixed in-house which should relieve some 12.06/12.07 pain:

  • Running out of memory mid-frame. Turns out if you got into a fairly tight situation VRAM wise (and we try to do that to max out the texture res you can have) then X-Plane might run out of memory trying to draw trees and…melt down like a toddler who can’t have any more candy.

    We have an interim fix: allocate memory statically so we always have it. In a future update we’ll reuse memory from other parts of rendering to be more efficient.
  • Popping out a window causes a big slow-down. When the arrangements of windows changes, we might need to allocate more VRAM for rendering. This is not a fast process – we have to halt all rendering, throw out the old memory, compact things, allocate new memory, and if a DSF is loading while this happens, the DSF loader is using up memory as we are trying to reallocate the windows, which can mean compacting memory again, paging down textures…you get the idea.

    The fix is pretty simple: don’t do this if the popped out window doesn’t require more VRAM. Most of the time, this is the case, so this is an easy fix for a silly bug.

Integration work for the next update is going on now and I’m hoping it will be done next week. More details soon!

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.

34 comments on “Two Pain Relief Fixes Coming Soon”

  1. Could you fix the FMS of the Cirrus-22 because we can not load a flight plan stored anymore , thank you

  2. When you say work on graphics, does that mean improving XP12’s AA? It’s a shimmer fest out here.

    2. Agree, Laminar seems to work on everything but the bad AA and shimmering, please fix the bad AA and shimmering.

  3. Using X-Plane with “spinning rust” I experience significant loading times. While waiting I have quite some time watching the “progress bar”, but actually that is quite poor: It stays at some position for a vrry long time, then makes a larger jump, and the process repeates.
    I wonder: Can’t there be a better progress bar?
    I remember back in the 80-ies Adobe seemed to be the only company providing a smooth progress bar during software installation. Almost 40 years later I wonder whether that’s still “rocket science”
    Any changes for improvement?

    1. Honestly….no.

      If Austin found out that I was working on the progress bar for scenery loading instead of _making scenery loading faster_, he’d cut my thumbs off, and then I’d go “hey, guess who has no thumbs and deserves it cuz he was working on the progress bar and not actually making the load faster? This guy!” Then I’d try to point my thumbs at myself and realize I was just getting my shirt bloody. It would be truly macabre.

      Seriously, there’s a bunch of pretty serious scenery system work that has to get done before this.

      1. Pardon my bizarre totally unrelated out of the blue question that just popped up in my head after reading that response but in an hypothetic parallel universe, would take over Laminar Research if Meyer would have to step down for whatever reason and ask you to? Keeping your thumbs being a contractual bullet point of course… Or is he going to cut them if you answer this question? :p

        1. If Austin were to step down we would immediately tie him to a poll with ropes because we’d know we really had a shapeshifter on our hands who had kidnapped the real Austin and infiltrated him. We’d want to contain the doppleganger while we sorted out where real Austin had been stashed.

      2. Well then Austin needs to learn about managing customer expectations by providing timely information. A slow scenery loader is easier to accept if you have timely information about progress. I can then do some other task knowing I have x amount of minutes before X-plane is ready.

        1. FWIW our design goal (and we are _not_ that close to it) is to have X-Plane load fast enough that it’s not a “do something else while you wait” kind of thing. We are not there yet, and I think our treatment of orthophotos will have to change quite a bit internally to get there.

          1. Here’s a thought – forget any accurately predicted progress bar. Just show a timer, next to an ‘average of last 5 loads’. Should work for most except devs who jump from ocean islands to ortho capital cities….?

    2. I agree with Ulrich – it would be nice to have a progress bar on loading, if it didn’t take too long to implement. I started a standard Boeing 737 flight the other day and it must have taken about 2-3 minutes to be ready.

  4. Hi Ben, I am home cockpit buildier , I use xp12 and a320 from flight factor, when I pop out the 6 displays via output.cfg , FPS down from 120 frames to 40 frames . ( I use RTX4090). Will 12.08 help with this?

      1. It happens the same to me with Toliss Airbuses and with Avitab.
        The exact moment I popout outside XP main window the FPS goes down, and it gets worse with each popped out window. Crossing fingers that the fix you refer to helps with this.

        1. Not to be the “Actually!” kind of guy, but 6 displays are a lot of pixels to render, obviously, but what kind of performance drop were you expecting? Not snarky, just curious, I don’t how good XP is supposed to be at running multiple displays…

          1. In my personal case what I found “weird” is that when you let’s say popout the Airbus PFD, ND and the 2 EICAS all WITHIN the XPlane system window there’s no fps hit at all, but if you click the popout to get those screens out of XP’s system window the fps sees a great, great drop even in the same physical monitor. So when I read about this fix hopefully addresses this problem.

  5. I understand, but older versions of X-Plane had a better progress bar. But I fully agree that faster loading is much more preferable.

      1. Being lucky to have a cpu with a lot of cores (and even more threads), I can confirm that scenery loading, even with complex custom scenery, got a lot faster compared to early XP11 times.

        I might file a bug though, that during scenery load my cpu fans always go crazy. ; )

        1. I think Philipp and Javier got that bug report back in xp10 when they released a version of the CRJ that could go wide – no x-plane user was used to that much core use. 😀

  6. Regarding anti-aliasing, it’s been found that if you edit the settings.txt file so that FXAA is combined with MSAA you get a good anti-aliasing result with minimal performance loss. I would be nice if the slider controlled MSAA and a simple checkbox to enable FXAA on top of whatever MSAA setting you choose.

      1. I can back up Paul’s comment. Running FXAA with 8 x MSAA virtually eliminates the problem here, and the fps is higher. (5900X and 3090ti)

  8. Nice! Good to see that there are fixes for this issues that fast 🙂

    Anyway I see you’re replying to comments so I will try to ask. I have bought X-plane12 few days ago, switched from another platform (before 2019 I was using X-plane 11 for few years). I have tested VR and it is working very smooth with my setup – but we have few strange bugs still (I will post them via bug report page) – anyway, question is.
    How much VR is priority in this stage of development? And how much do team focus on its features?

  9. Great update, thank you! These are enormously appreciated even if I only rarely leave a comment.

    In the discussion on discord you have explained why speech synthesis for Linux will not be supported by Laminar. The argument was quite understandable, unfortunately.

    Would it be possible that Laminar implements a data-output containing the spoken text, ideally also the region and the speaker (pilot, ATC 1, …)?

    I ask because would be trivial for the community to provide a little script and instructions for those who are interested, converting such a data-output into speech on Linux. I have even written one such script myself calling the pico2wave package.

      1. Cool! Many thanks for talking to Jim.

        In case that is going forward, ideally headings would be written to text as “2 5 0 degrees” instead of “250 degrees” so that the synthesizer generates the correct speech of “two five zero degrees”. Similar for ‘1 2 thousand’ and so on. Quite likely something of that sort is happening in your own code talking to the system built-in synthesizers, too.

        If the text for the pilot and all other entities is written to a text file line by line it is simple to watch that file with inotifywait, read the last line when the file changes, convert it into speech with pico2wave (maybe using sox to modify the pitch and speed to generate different “voices”) and send the result to the audio channel.

  10. Can we please have a third pain fix? When flying, I use my headphones plugged in a different Windows output source, and my non-flying computer use is on my 2.1 speaker source. X-Plane 11, & now 12, does not let us switch between sources after the sim is launched, whereas the majority of other common applications do allow us to. Imagine having an hour or so to fly, 5-7 min used by sim startup, then starting a set of procedures and maybe 20 minutes into one’s 60 min sim session they realize they are on the wrong sound source? UGHHHHHGHGHGHG!!!!!! ~ Because changing it to what we need requires a sim restart. Can we have an update that gives us this functionality please?

  11. Paul and Brian, can you post the exact syntax of your FXAA and MSAA settings mod, so that others may experiment please?

Comments are closed.