Many thanks…
Is anyone seeing full black screens when switching between windowed and full screen MSFS using the DLSS DLL version 3.6 or 3.7? If I go back to 3.5.x the issue stops. I can start MSFS full screen or windowed and it’s fine. It’s only when switching does my whole screen go black.
We need a native implementation of the game, which allows to render the instrument or the glass panels display in the cockpit at full resolution and leave the rest to the resolution chosen by the user processed, with DLSS. Then with different levels of DLSS in different sectors of the screen.
I’m on 3.7 but don’t have the issue with the screen going dark.
It’s frustrating that the Devs mentioned it during a Q&A in the Spring when asked about what’s going on with this fix, Martial incorrectly thought it was in the Sim and fixed but was told via text message it wasn’t. Jorg then asked him to chase it up and yet here we are, mid summer and still no word on whether this fix is incoming.
Is it at all possible that you, as a moderator, can ask the question about what’s going on with this? We shouldn’t have to rely on the off chance a Q&A question will remind them, they need to realise the importance and implement this fix in SU16 if it’s ready to go.
Thanks
I have submitted a question regarding this matter for the upcoming developer livestream. Let’s see if we get a response.
Hi everyone,
When is DLSS going to be fixed for glass cockpit? They said in the developer stream (July) the developer was on holidays and it was pretty much fixed. There’s a significant difference in performance and currently DLSS it’s very annoying to use.
It was said in the latest stream a few days ago that the problem cannot be fully fixed because of how the DLSS algorithm works, and it’s the best it can be right now.
Listening to this again, there seems to be a fundamental misunderstand about what the actual problem is. Martial explains that DLSS get’s a bit blurry due to the upscaling inherent to it. But that’s not the issue that keeps the community from using it!
What we have as an issue is that, the the temporal component of DLSS is not biased for the current frame in the glass displays, which smudges numbers into an unreadable mess. This is totally independent from the upscaling and even happens if I use DLAA, which is only using DLSS for anti-aliasing, not upscaling.
And I’m very optimistic, that this should be a simple fix by setting some flag somewhere. Afterall, with their own TAA implementation it does not happen, even though TAA and DLSS are exactly the same in this regard, that they work over multiple frames.
(you can even see, that they don’t use TAA on displays in some addons, eg. the EFB and the PFD in the PMDG 777, since these very much display some slight aliasing. So you just need to apply the recent frame bias option for DLSS on these very same textures)
Now actually though of demonstration for this issue, since they say a picture says more than a thousand words or something along those lines see the altitude tape here in Fenix A320, the numbers in the readout are almost unreadable and the tick marks wholly disappear
Also very visible in this video. I’m scrolling through the baro settings here to just get some movement on the altitude tape for the demonstration.
Compare this to TAA with the exact same settings that doesn’t blur these numbers and stays readable
Martial explained in that Q&A that they are already flagging glass cockpits and other animated textures (such as the water surface) to bias current frame information on them. The problem though is that DLSS insists on performing a temporal reconstruction pass on these surfaces, rather than ignoring them completely.
The same thing is happening with the FSR 2.1 implementation. The glass cockpits and water look extremely jittery because Asobo have correctly flagged them for the reactive mask, but even that is not enough to prevent ghosting. This is because, despite the stronger reactivity, the FSR algorithm struggles a lot with animated textures and elements without motion vectors (this can be seen across several games, and is not an MSFS issue).
Meanwhile with TAA the glass cockpits look perfectly stable because the algorithm ignores them completely (even from the camera jitter). But that is because Asobo have full control over their own algorithm. The solution would be for Nvidia to allow full reactivity of flagged elements.
Alright, that’s a shame then that nVidia can’t handle that on their end properly. Thanks for pointing that out, must have missed that piece of information in the stream.
But that leaves a slight hope, that some update to DLSS might acutally fix this one day without much more involvement from Asobo. Maybe just need to pump more resolution, cause I saw in my testing that once the numbers get big enough they stay clear even on DLSS.