ColinM9991

Although it's not an option for everyone, I'm running 2.7 alongside 2.8 as I have very little hope in this bug getting past the preliminary stages of bug reporting. Considering the conversation so far has been focused on user settings, and not the clear difference between 2.7 & 2.8, I'd bet this is one of those cases where a bug becomes a feature.

I've just read that comment. That all looks really good. Thank you for putting your time and dedication in to improving the presentation and readability of the documentation.

I'm a little bit confused by the "cannot reproduce" tag and the fact that we're still talking about this as if it's solely a VR and user graphics issue. It is an issue that affects VR and 2D. It is an issue with DCS in the 2.8 update, it is not an issue with any settings that users have configured that have not changed between both versions. I have already provided comparison photos taken in 2D, not VR but 2D, that show a clear difference between 2.7 & 2.8. To say it again, on my end absolutely nothing was changed in Nvidia/AMD or in-game graphics, aside from the inclusion of the new shadows setting, between my test on 2.7 & 2.8. In case it has already been forgotten, here is the comparison photo that shows a very clear difference in the weight of the text. There has been no editing of this picture other than to include the version. What incentive is there to report bugs if the evidence is just going to be ignored? At this point I cannot understand how the difference in this photo is not being recognized. The reproduction steps are 1. Take a screenshot of the MFDs in 2.7 2. Take a screenshot of the MFDs in 2.8 3. Compare the screenshots 4. Look very closely at the definition of the text.

Wags viewed the thread last night and it is now set to "Investigating". So, fingers crossed that the team is looking at this now. I agree with your sentiment. It is difficult to believe that 4.2 introduced a very different behavior than what is described in 3 & 5.

Yeah, I think this thread has served its purpose. It's certainly starting to devolve into insults and attacks now.

So you're saying the 4.2+ handbook has a different process than 3 & 5.1 (which was previously shared here, but now deleted)?

Vulkan and Multithreading aren't a holy grail. What we'll likely gain in FPS, as a result of these, are the FPS we lost over months of updates. Optimizing DCS requires far more than these two, it requires a change in mindset to prioritize optimization first. Changelog history shows a repeatedly poor pattern of optimizing last, especially when it comes to LODs which have taken years to implement such a minute and simple concept. Not to mention the current problems, such as the ballistic issue, that continue to hinder the experience in DCS. If there was a genuine care for performance and optimization, those issues and bug reports wouldn't be sitting around for months or years. Phrase it as diplomatically as you want, but this is the reality.

I'm currently waiting for my 13900KF. Now running a 9900k I was hoping to squeeze out some more frames by essentially building a new PC. ED obviously had other ideas for everybody who were happy with their 4090s.

W10

Use the -w switch on the DCS exe Example: DCS.exe -w DCS.openbeta DCS.exe -w DCS.myinstance These will create the following directories %userprofile%\Saved Games\DCS.openbeta %userprofile%\Saved Games\DCS.myinstance I use this to run VR and 2D instances. Also, to share bindings, I use mklink /J "%userprofile%\Saved Games\DCS.secondinstance\Config\Input" "%userprofile%\Saved Games\DCS.maininstance\Config\Input" This creates a directory junction in DCS.secondinstance\Config\Input that points to your main game instance/folder, assuming your controls/bindings are there. Given the fact that controls can sometimes unwrite themselves, you could even sync the Config\Input folder with OneDrive and then junction that to maininstance and secondinstance. That way your bindings are always backed up.

Bear in mind I took these screenshots in 2D to show that the issue is not limited exclusively to VR, as demonstrated in the comparison photo above. Certainly, the readability is impacted in VR but I don't believe this to be solely a VR issue. Something has changed with the MFDs, or the font weight on the MFDs, that impacts both 2D and VR. As you say, it's harder to see in VR due to resolution, pixel density and general VR limitations. The STAT page is by far the worst with multiple colors that bleed into one another. Maybe both of these threads should be merged. I raised it here initially as I thought it was wider than the A-10C II but it does seem that's the only affected module at the moment.

For reference

I wonder if this has to do with reflections on the MFD. I've attached two new pictures from the latest patch (recently released). It looks like the MFDs, when flying through clouds (second pic), looks somewhat clearer though still very different to how they looked in 2.7. Shortly after, I emerge from the clouds (first pic) and the text becomes somewhat darker and thinner again.

I wondered if it was exclusive to VR and, admittedly, when I first took screenshots in VR I deemed them to be too poor in quality to show a difference since it was very hard to see the cockpit. The screenshots above, and where I do a direct comparison, are in 2D running 3440x1440 on the High preset with 2x MSAA. Notice how in 2.8 text has less glow around it and it's a slightly darker, more vibrant green. The RWR and other systems are unaffected. As the differences appear in 2D, I don't think it has much to do with VR settings. The main problem in VR is the knock-on effect of text being harder to read. Between switching branches (Stable & OB), no graphical or resolution settings were changed, to reduce as many factors as possible, and I stuck with 2D in both tests after I noticed first in VR that it had become more difficult to read the MFDs whilst sitting back. FWIW, I'm also using PD 1.0 but running OpenComposite so the G2 is at its native resolution (50% of what Steam VR Resolution is typically at).

Apologies for the spam. One more screenshot which is a direct comparison between the MAV page in 2.7 and 2.8 where you can see less font weight in 2.8. So not glowing as much as 2.7 and smaller text size .

VR settings as requested null Have also attached my Nvidia Control Panel 3D settings but should mention that I haven't changed anything here in the past, that I can remember, nor have I defined any per-application settings. Additionally, I've included my options.lua too. options.lua

Update 11/07/2023 I asked the dev team directly whether this was an intentional change, which they've confirmed is the case. sRGB was added to the A-10C in 2.8 as an improvement since the text was over-saturated in previous versions. Since this has had a detrimental impact to the readability of text, I've asked if they could potentially increase the thickness of the harder to read text; they've said they'll take it into consideration. Why the community managers couldn't put these questions forward, since that's ultimately the job of a community manager, and why I had to reach out directly are two things I'll never understand with bug reports on DCS.. Note: Issue and temporary fix identified. Skip ahead to the following comment. The issue is caused by input_space_SRGB which was added and enabled to the MFCD displays in 2.8. This makes the text lighter due to having less colour space available. This change remains to be undocumented in any changelogs nor has any developer or ED Team member confirmed that the change is intentional. Original Post Please read this comment in it's entirety so you don't make a suggestion that has alread been tried. Raised this on Discord but figured the forum is the best place for it. There's a degradation in the quality of the MFVCD text in 2.8 which isn't a problem on 2.7. No graphics or MFCD settings were changed between screenshots. While there isn't a great difference in 2D, they are pretty unreadable in VR for the A-10C II unless you use the VR Zoom binding. I've taken 8 pictures in total, 4 from v2.7 and 4 from v2.8 that cycle through each MFCD page in the A-10C II. So far, the following steps have been performed as an attempt to resolve the issue. None have yielded a successful result: Repairing the game Reinstalling the game, manually verifying that the DCS game directory was entirely removed prior to reinstalling. Deleting the DCS directory from Saved Games, to start with a clean slate Deleting FXO and Metashaders (I perform this after every update, naturally) Tested on 2.7 and 2.8 with no graphical or setting changes, to demonstrate the issue being present only in 2.8 and onwards. Adjusted Resolution of Cockpit Displays to various values Adjusted brightness values as you've mentioned above. Several other users have provided their results in this thread too, the displays can't be returned to their original 2.7 brightness. Haven't changed any Nvidia Control Panel settings and I'm loath to do so as the A-10C & A-10CII are the only aircraft with this issue. So I'm of the opinion that this isn't related to anything external of DCS, but happy to be corrected there with tangible evidence. Excuse the double post. Here are the next 4 pictures from 2.8. It becomes really noticeable in the last 2 pictures for 2.7 & 2.8.

Although the changes have been merged, the upstream doesn't yet work due to a compilation target difference. I believe it's been compiled against Vulkan rather than D3D or Win32. Nonetheless, I assume that the upstream will become the main source again once these compilation issues are resolved. For now my GitHub repository will remain as is but I may archive this in the future, unless, of course, I catch up with the upstream dev and see if I could convince them to set up GitLab Releases similarly to how Jabbah did.

I assume it's for everything. It makes sense for the changes to be included in the upstream repository since it's an extension and not a rewrite. Plus, the devs are working well together in Discord.

Jabbah's changes have been merged into the upstream OpenComposite repository here https://gitlab.com/znixian/OpenOVR/-/tree/master. Not sure if Jabbah's version will be supported going forward. Unfortunately, my OvGME GitHub repository won't be updated to support this since the upstream doesn't have a very well refined release process. The download process is to essentially download the DLL files from the README in the upstream.

Thought it would be worth sharing this here. This is from the recent WMR for SteamVR changelog. Apparently this update is quite unstable with DCS, but I'll play around tomorrow to see if there are any differences in performance or smoothness with SteamVR now.

v0.6.3 is live on Github(OvGME) and GitLab (source)

I'm 2 years late, but could you share a bit more on this? I'm also looking to run VR and non-VR at different times.

Speaking of reprojection bubbling, do we have any steps for resolving this? I get generally good performance but tried with reprojection on Saturday and had quite a bad case of bubbling. Running on Windows 10 with a fresh install of DCS, OpenXR Toolkit and OpenXR for developers, Steam version of DCS, WMR4SVR installed via Steam too.

Jabbah, the OpenCompositeACC fork maintainer, has been very kind in working with me to introduce automated releases to my GitHub repository. Hopefully, from here on in, my GitHub repository will be scheduled automatically as and when a new GitLab release has been created. Unless the repository has issues or something breaks, my job here is done. Enjoy!