mbucchia

The change in the unsigned DLL only enables the workaround for ED's bug like it did before. Your micro-stuttering issue is unrelated to any of it. There is no connection between Quad Views and OpenXR Toolkit.

Good question, and it shouldn't matter whether the workaround is still active. Also, assuming ED didn't revert the app name change, then the workaround won't be activated anyway. What matters more is to remove the unsigned DLL (for those who installed it) and reinstall the original (signed) qvfr.

Great to hear, thank you.

Can you describe "fix"? Is it going to be the real thing (correct FOV submission) or just reverting the name of the app back to "DCS World"? Thanks.

The OVRPlugin stuff doesn't apply to DCS, but instead the large majority of new Unreal and Unity games. This examples serves to explain the deplorable state of PCVR, where developers only target Quest Link, meanwhile Meta is abandoning PCVR, so this leads to that, aka leading to the unavoidable death of the industry.

You are still worried about the wrong things. As someone who is investing in non-Meta headsets, you need to be extremely worried at the game developers' attitude associating PCVR to one thing only: Quest Link. Developing only for Quest Link, using Meta's broken/proprietary tools, and testing only on Quest Link. There are several games in 2024 that released with only Quest Link as supported devices. The developer did not bother testing on anything else. That is the problem that should keep you up at night. The quad views API layer is very simple and isn't going to break because I don't maintain it. You can still install Windows 98 on your PC and play Half Life 1 today. It's solid code that isn't just magically going to break. Just as proven this week, it's the content and the lack of validation by the game developer that breaks things. If tomorrow a developer file to me a bug report in PimaxXR with the degree of detail that I put in my bug report to ED, I have no issue actually fixing what is broken. But the reality is a game developer in 2024 wouldn't even bother looking into the issue if it isn't affecting Quest Link users... I have conversations with at least 3 major game developers this year that proved my statement. Focus on the right problems and evangelize these problems.

Just to be clear if it wasn't enough in my message, I'm not pointing finger specifically at ED. What they're doing isn't really different from the many other game devs I haven't been able to get through to. You should consider yourselves lucky that you can actually play DCS on non-Meta headsets at all. More and more of the new content from game developers isn't going to be tested on anything other than Quest and given Meta's approach to a locked-down OpenXR ecosystem, this content isn't going to properly work on other headsets. I'm dipping because I don't have time to deal with folks who aren't interested in being constructive and solving real problems like this one. (hint: Meta is top of the list)

My wife and I rescued a 2nd abandoned bunny from the street last year. I think we have full house now

Addressing this separately btw - I left the VR industry about 1.5 months ago. What I mean by "left the industry" is I quit my job as a professional XR developer. Why did I? I don't really believe in this industry at this time. Point proven as follows: - game developers don't care. I think today's situation is an evidence. PCVR gets very little attention from them. For most developers today it appears that "VR support" means "the game runs (even poorly) on a Quest 2". This is because of the volume on the market. - platforms vendors don't care. You can see that Varjo, Microsoft, left. As for Meta they are clearly only interested in wireless (standalone) and glasses, and they haven't really done anything positive for PCVR in forever. Worse: they are currently creating a silo'ed ecosystem with the help of game developers, through something called "OVRPlugin" which basically nullifies all of the benefits and work that the industry has done with OpenXR in the last few years. Most games released so far in 2024 use OVRPlugin instead of OpenXR: this means they cannot run with OpenXR on non-Meta headsets. - game developers and platform vendors really don't care. I've brought attention about the problems above on many occasions, reported issues, I've created "band-aids" for these issues, and nobody else in the industry has cared. The amount of details you saw on my report of the bug to ED, that's about the large majority of what I've been doing for over 8 months now. Spending hours of my personal time at 1:00 in the morning documenting other people's issues and recommending fixes. And none for them get acted on by game developers and platform vendors. For over 8 months now I had no opportunity to innovate and do the things I actually enjoyed doing (like back in the early OpenXR Toolkit and QVFR days). Instead it's been trying to salvage what I now believe is unsalvageable (again, I am speaking broadly, not specifically about ED/DCS). This week is the most time I've spent on XR stuff since I left my job, and it was unsurprisingly, negative and uninteresting to me. I'm currently doing some wrap-up/life support on VDXR, but my plan is a full exit, not only professionally, but also from all of this open source/community work, in the next few months, so that I can focus on my new job (which is the real gaming industry and not the XR farce), my sleep/health, my new house, my hobbies and my future. That's a lot of "my" stuff I haven't done in 3 years now.

Fred provided a very good reply to you, you can also go read my detailed explanation here: For short: ED is mostly doing the right thing already (minus the bugs :D) and there is a bigger chunk of the pie that isn't "on them" to provide, but on the headset vendors. Today only Varjo provides it, and perhaps Somnium I am told. Other vendors rely on my API layer. That's a platform vendor deficiency, not and ED deficiency.

You can see my earlier post. I installed today's version of DCS and provided a very specific capture of the problem, proving without any possible doubt that the issue is still there after 18 months.

You are getting this error because you must have OpenXR Toolkit installed. When you followed the instructions for Varjo-Foveated, you disabled OpenXR Toolkit for "DCS World". Because they renamed the game "name" to "DCS" in this release, you now have to go back to OpenXR Toolkit Companion app and disable it for "DCS". This should resolve your problem and let you use Varjo-Foveated without issue. The band aid that was provided by another community member, as I explained, will break every other OpenXR game that uses anti-cheat (due to digital signing issues). So that's not really a good band-aid. Most people will forget that they have the bandaid and will start getting unexplained errors in those games. That's not a very good solution. Stop bleeding in one place and start bleeding on others, I don't even call that a band-aid I don't have an option to do code signing at this time, but @actually_fred is sharing his expertise on the topic with me so perhaps I will be able to do that again in the future.

My recommendation is to skip the band-aid and to keep making noise for ED to fix the real issue. There's never going to take responsibility and commit to deliver a robust product if they keep getting bailed out by 3rd party developers.

I replied to you in the other thread. I've crossed the line a few times probably, but they never moderated me, so no need to read things that aren't there!

No that's something I put in my signature a while ago. I don't read DMs, but I come sometimes here and there and check out threads. FYI I no longer work in the VR industry and barely do any work any more on open source projects. ED had never censored me or treated me poorly for my posts. I speak my mind, sure. They probably would have cause sometimes to moderate my posts but they don't. I wish there had been a bit better listening from them. It's a bit late now since as I me mentioned I no longer have time for this stuff.

AMD doesn't support foveated rendering with DX11 apps. See the compatibility chart and documentation on the website.

Time will tell you if it breaks in some scenarios, I'd expect it will. I gave instructions like 2.5years ago to ED on how to make OpenXR Toolkit FR work, and guess what they did? The same thing they always did with anything I wrote to them: they ignored it. Even if it might work in today's update, good luck with next month update... Regardless, VRS foveated rendering (OpenXR Toolkit) will give you much much less of a gain than quad views, unless you have very little CPU headroom. You're not going to see the +50 +100% boosts of quad views. Perhaps +20% at best.

Edit: I shouldn't be ranting so I'll edit my post. Bottom line: please start holding the right people accountable instead of this false impression that you have. ED literally has a blatant BUG in their code. THAT is the problem, existing since Day 1 of DCS OpenXR support. Reported to them on many occasions in the last year and a half.

Please please please stop calling the unofficial build a "fix", because it is anything but a fix

But how do you think DCS loads this DLL? It is installed system-wide via a registry key (what we call "Implicit API layer loading"). Every single OpenXR game that launches will go and load that DLL, regardless of if it's DCS or of it uses quad views at all. There is no way to "filter" the loading of the DLL for each game. We have to cast the wider net - aka ALL OPENXR APPS - and them the API layer has detection logic for whether it is needed or not. The problem is that this detection logic is inside the DLL. So the lack of signing will make all OpenXR apps try to load the unsigned code, which will flag all anti-cheat software.

See the unsigned DLL will screw up ALL OpenXR games that have anti-cheat, regardless of whether these games use or not use quad views. It will make them fail in a way that will also pop up my name on the screen "failed to load XR_MBUCCHIA_quad_views...." aka pointing fingers at me This is why I'm not distributing the unsigned DLL. Some examples of games using OpenXR and Anti-cheat that will break with an unsigned DLL system-wide: Pavlov, WRC, Contractors Showdown, Roblox... In others words: people are going to copy this file, forget about it, then eventually they will run some game that will crash, point to me, and people will come and complain that I broke their games On top of that, PLEASE, we have to stop bailing out Eagle Dynamics. They wrote some buggy OpenXR code. They need to fix it. By having people adding more and more duct tape to "hide" their problems, we are removing their accountability and continuing to deepen the problem. They're not going to take this seriously and do the proper fix, if we keep bailing them out:

@BIGNEWY I am going to write this up one more time, especially since it looks like my message from March 2023 was partially lost. The following trace is captured today with DCS MT and quad views enabled on a Varjo. But it doesn't matter, it's the same issue with Pimax, Quest Pro, etc. The trace shows 2 consecutive OpenXR frames (xrBeginFrame -> xrEndFrame). As reminder, with quad views, per OpenXR 1.0 spec section 12.143.1 > The first two views (XrViewConfigurationView) will be for the left and right eyes for the outer viewport. The views 2 and 3 are for the left and right eyes for the inner viewport. This means in the trace below, when you are seeing 4 consecutive "xrEndFrame_View", the bottom two are for the inner viewport (the region that moves with your eye gaze). This trace clearly exhibits the bug in DCS frame submission code. The order of operation might look confusing at first: this is because in MT mode, the processing (on CPU) of frame N+1 begins before the processing (on both CPU and GPU) of frame N ends. 1) The top of the trace corresponds to frame N's pre-processing. Frame N has a predicted display time of 1000084542856849400, and the tracking data needed in order to render that frame is queried through the xrLocateViews() API call. This call returns the data necessary to compute projection matrices for all 4 viewports that need to be rendered. We observe, circled in green, the values for the FOV of the inner viewports. 2) Meanwhile, DCS performs rendering and submission of frame N-1, with a "display time" of 1000084542846147700. This is the xrEndFrame() call that we see in between the green and red annotations. We sort of don't care about frame N-1 here, so let's just move on to frame N and N+1 to understand the problem. 3) The engine is now going to perform two things in quick succession: it will begin pre-processing of frame N+1, through a call to xrLocateViews() similar to what we've already described, and it will render and submit frame N. Remember frame N: the one we pre-processed earlier, at the very top of the trace in 1). a) We see the call to xrLocateViews() for frame N+1, annotated in red, with a predicted time of 1000084542868214700, and that returns a new set of FOV values for the inner viewport: this is because the eye gaze moved between frame N and N+1. b) Right after that, the succession of xrBeginFrame+xrEndFrame() corresponds to frame N being rendered and submitted. You can see a jump in time of about 8ms... that's our frame time. We can tell this is the submission for frame N because we look at the value of "displayTime" circled in green, and it is the same value 1000084542856849400 that we saw being used in step 1). 4) Now here is the bug: when you look at the FOV values that DCS was returned in step 1) and computed its projection matrices with, and you compare them to the "UnpatchedFov" values that DCS is submitting in step 3)b), they are not the same. DCS is telling OpenXR: "you know the inner viewport you gave me earlier to render into? well I didn't use that! I used other values instead, so you will have to perform reprojection from the viewport I used into the viewport you need to display on screen". This reprojection causes the freaky glitches we are seeing. You can also observe next to these "UnpatchedFov" values, the "Fov" values that are the correct ones: this is the workaround that Varjo-Foveated and Quad-Views-Foveated implement to mask this bug. It keeps track of the displayTime used in 1), then it stores the FOV value and retrieve them in step 3)b) based on that same displayTime. This is the workaround that today is only enabled when XrInstanceCreateInfo.applicationInfo.applicationName is set to "DCS World" - the value you were passing for 1.5yr, and that today you changed to "DCS", which causes the workaround to not turn itself on. But what we need really, is DCS to submit the correct values here. Now to go even further into it, and to tell you exactly what line of code you need to look into, here the other observation: in step 3)b), instead of submitting the FOV values acquired for frame N in step 1), you are instead submitting the FOV values acquired in step 3)a) for frame N+1. This is the result of a very simple bug. As you can see looking at the Thread column, there are two threads working here: thread 32252 which is doing the pre-processing (xrLocateViews) and thread 27000 which is doing the rendering and submission. My guess is that your code is using a single set of a shared variable between the two threads to "carry" the XrPosef/XrFovf values from the calls to xrLocateViews() into the calls to xrEndFrame(). This approach is fine when you are doing single-threaded, sequential frame processing. But since here you get started on frame N+1 before frame N is submitted, you overwrite the content of the XrPosef/XrFovf that you have stashed between your two threads. Note that you do not have this problem for the value of the displayTime: you are correctly retrieving this value from xrWaitFrame(), passing it to xrLocateViews() on your pre-processing thread, and eventually carrying it into xrEndFrame(). So whatever logic you are doing today for the predictedDisplayTime/displayTime between your two threads, you want to replicate that logic for the XrPosef/XrFovf values as well. You need a latching mechanism for these values between the moment you use them for computing your projection matrices and to carry them along with your rendering into your submission thread, WITHOUT overwriting these values with the "most recent" values when you start pre-processing frame N+1.

All of the above would resolve your issue, but of course with the potential to reduce performance.

It's possible (but unlikely) that the game engine is now rendering left and right eye in a different order. I highly doubt this really works, all of the previous experiments with this showed that either FR wasn't really applied (no gain) or FR was incorrectly applied in certain situations (unexplained blurriness in the middle of the screen). For VRS to perform better than QVFR, you must have had extremely low CPU headroom, which isn't the case of the large majority of QVFR users.

To be very clear, the unsigned DLL will screw up ALL OpenXR games that have anti-cheat, regardless of whether these games use or not use quad views. It will make them fail in a way that will also pop up my name on the screen "failed to load XR_MBUCCHIA_quad_views...." aka pointing fingers at me This is why I'm not distributing the unsigned DLL. Some examples of games using OpenXR and Anti-cheat that will break with an unsigned DLL system-wide: Pavlov, WRC, Contractors Showdown, Roblox... EDIT: FYI this is the bill for getting a digital cert in 2024. Per year. We can thank the anti-cheat companies for that. I wish Epic and friends would pick up that bill... null