Headwarp

Been awhile since I've used a monitor rather than VR in DCS, however I find that there are quite a few titles that will exceed the max refresh rate without v-sync on, g-sync will still sync if the frames drop below the max refresh rate, but will exceed max refresh rate if system has the horsepower to do so. I have seen enabling G-sync in some titles take care of both however. So YMMV. I have seen nvidia driver versions where g-sync in windowed mode refused to work. I've also seen windows updates cause issues with nv drivers in this regard. So future updates may resolve that if it's happening. Cool that you found a workaround AD.

I'd imagine support for more freesync monitors is coming in the future. This is just the first step. Kind of surprising to be honest that nvidia made this move at all. It's about time. Running above 60hz is a step up imo.. at least in like first person shooters or something. I find that kind of gameplay much smoother at about 85fps compared to 60.

Should be the only two settings you need to adjust to enable g-sync. Vertical sync left on application controlled.. which i usually leave on in games so my fps doesn't exceed my maximum refresh rate. I would see if you're monitor's on that public spreadsheet I linked in a previous post, as it may give you info on whether or not other people are having success with the new driver and what steps were taken to achieve. I looked at it and saw one listing for the HP Omen, didn't say too much except it seemed to work in Pendulum.

There were only 12 freesync monitors certified by nvidia. Here's a public spreadsheet, where people have reported successful or unsuccessfull and in some cases the steps required to get things to work. https://docs.google.com/spreadsheets/d/1YI0RQcymJSY0-LkbjSRGswWpJzVRuK_4zMvphRbh19k/htmlview?usp=sharing&sle=true I anticipate support for more monitors over time.

You shouldn't have a problem using a single nvidia GPU. Might be some concern if you were to ever attempt SLI.. which most of us don't. http://www.tomshardware.com/answers/id-3493494/ryzen-nvidia-sli.html

Cool they finally did this.. wish they had done it when I was shopping for monitors. LG had a nice ultrawide that would've cost me less and had some pretty nice features compared to acer, but it was freesync >.<

Mhm. I've read what you've already stated. That doesn't change, that people are reporting this issue at different pixel density levels, and we have no idea of knowing their SteamVR settings.. indicating there's some point at which above a certain resolution you're getting the white box.. whether it's simply a coding error.. which it could very well be.. or something un-anticipated like a windows update which has been breaking crap all year.. not being an eagle dynamics programmer I'm not in a position to say what the issue is..so I cover the bases. I use the Odyssey.. the screens for both headsets are 1440x1600 per eye. What changed is the perceived pixels per degree of view. Personally above 2.3 PD I become gpu limited and also tend to drop below the 45fps minimum for motion reprojection at low altitudes.

I'm not saying ED won't find the cause of the white screen and come up with a fix. Rather than say - "they aren't meant to be used in tandem" i will say to me it seems like overcomplicating the matter of SS. Using either option I can read my guages using the Odyssey and maintain 45 fps at the lowest altitudes. Objects in the distance will still blurr. 200% in my headset is already asking a lot of my 2080Ti. Pixels per eye about 5.1 or 5.2million. Thats more pixels than my 3440x1440 monitor per eye. The relevance of that, is it seems the white box has something to do with the amount of pixels being drawn, whether it comes down to a bug, GPU capability, or something gone awry with drivers or newly released windows updates. This is supported by multiple threads where people are reporting different PD values causing the box, some of them likely unaware the steamVR application resolution sliders even exist. In other words I think you've stumbled on the one common factor concerning complaints of this particular issue, as I haven't encountered it..but probably could based on your information. I'd say your workaround, however for the time being is to stick to one or the other. That also just happens to be advice I'd give someone setting up their headset for the first time.

Yes it is true.. they may produce a different supersampled image due to being different methods of doing so, but you can set a higher amount for either if you only use one or the other. They are not meant to be used in tandem, both are requests for an increase in rendered resolution. fact. Resolution defines a set amount of pixels configure by aspect ratio. Increasing resolution, increases the number of rendered pixels. The phrase pixel density refers to how many pixels are being rendered in a scene, or the resolution. You see that the "supersampling" sliders in steamvr are now labeled "Application resolution?" You are applying 150% supersampling, to an image that is already supersampled 200%. hence it looks sharper. Try setting a pixel density of 2.5, or 3.0 with your steamVR slider set to 100%.. and presto that image will also be sharper than 2.0 pixel density. Two different methods of reaching similar results. Use one or the other. Problem solved. You see that steamVR slider goes all the way up to 500% right? You also aren't limited to a pixel density of 2.0 Raise JUST one until you can no longer maintain 45fps then bump it down til you can. ez pz. White box or not.. doubling up on SS imo is redundancy.

Better to have too much wattage than not enough. Not enough can cause damage. I'm fairly certain most general consumers aren't running around with multi-meters. And frankly there are generally enough sales going on throughout the year that you can find a decent modular 750w or higher psu for pricetags that you can recover from pretty quickly. Not to mention if you buy from like evga there's a 5 or 10 year warranty on a psu. Buy an extended warranty they'll cross ship should something go wrong. We dont even know that this guys issue IS his PSU, but it sounded like he was going to get a new one at some point anyway, along with a new build.

You're meant to use one or the other not both. The SteamVR supersampling sliders are there for games that do not have their own built in supersampling options. The pixel density setting in VR is DCS's implementation of supersampling for VR. Both are simply an increase in rendered resolution, aka an increase in the amount of pixels being rendered. the values for PD represent percentage i.e 1.0 = 100%. leave one at 100% which represents your native resolution, set the other to the highest value you can while still maintaining at minimum of 45fps. Unsure what the difference between 2.5.3 and 2.5.4 causing the white box... doesn't change that using two different methods of supersampling is redundant, especially given that you can set either to pretty high values. You're asking for a lot of pixels per eye.

idk i've been using 417.35 since the day it released without any issues. I only use openbeta but there've been more than one update to OB in the time that it's been released afaicr. Did you get a blue screen of death before the PC restarted after disabling automatic restarts? In my experience it usually points me to what needs fixing. Not directly, but with a little help from google. https://www.guru3d.com/files-details/display-driver-uninstaller-download.html saying this happened after a nvidia driver update, run DDU in safe mode, which can be downloaded from the link above and then reinstall nvidia drivers just to be sure something janky didn't occur with your driver installation. You'll have to re-add dcs.exe in nvcontrol panel of course. There have also been several pretty important windows updates since oct. but im sure you checked that already. Or IMO - just stick to open beta if it's working lol. There's really no need to have both stable and open beta installed on your system and most MP servers seem to run OB anyway.

First things first, you need to disable the automatic shutdown of windows 10. Then the next time this happens you should get a BSOD that might point to a driver that is either going to be an indication of hardware failure, or faulty drivers. https://support.hp.com/us-en/document/c03413399 <--this explains how to disable automatic shutdowns in windows 10. Hopefully, it's something as simple as a driver update or flashing your bios rather than a piece of hardware on its last legs. PSU would be my first guess if updating driver software and windows updates don't get you sorted. Check your motherboard manufacturer's product page to see if any drivers/bios updates are available, run windows update through cortana just to be sure there's not a pending download or something. Make sure you have the latest nvidia drivers and possibly use DDU and reinstall them just to be on the safe side. You might find your fix without having to experience another BSOD there.

looking at the resolution per eye in your screen shot... it looks like you forgot to adjust the slider in the "Video" tab of steamVR settings and check "manual override" on Video tab in the steam vr settings and it's effecting the resolution on your "Applications" tab. And then use either the application slider on the application tab in steamvr settings, OR the pixel density option within DCS. One or the other though not both. also To the 9900K + 2080Ti getting drops to 30 fps, I'd wager there's a setting somewhere you have overlooked if not the very thing I described above. I find disabling texture filtering options in NVControl panel causes a bit of a performance hit so I just leave it at "Quality." If it's not due to some kind of overlooked setting - I'd make sure my background tasks weren't using more cpu than usual, as well as check for driver updates for all of my hardware. You can disregard this apparently if you're getting these results where there are static hornets parked (i.e. visual placeholders on the ground) I'm running 200% supersampling in DCS and never drop below 45 fps in my odyssey with msaa x2.

Buying a 9900K and disabling hyperthreading is like spending $200 more than MRSP for a 9700k 0.o Try process lasso to set DCS to run on physical cores instead imo. Be sure to exclude games/DCS from probalance.

Lol, I do mainly DCS for the modern combat aircraft.. so yeah. Limited use. That being said, I'll get my 30 bucks out of it.

Static hornets i think are known to be causing fps drops at the moment. I've always used just 512 rather than 512 every frame personally as well.

Assassin's Creed Origin's, and Odyssey use AVX operations. Sorry mods for mentioning other games, but, it's not to compare with dcs.. just to state that yes.. there are games on planet earth that use AVX operations, something about they handle certain aspects of the game faster than traditional methods. These games put every physical and logical core of my CPU at 99% right next to gpu running at 99%. And that's fine, because my OC averages about 75C completely stable during avx testing, with full mouse movement through the entire test. No hitching or hard locking. Who knows where we'll be in the next 5 years as vulkan/dx12 become more popular and the introduction of new technologies like the NGX sdk, not that all of this statement applies to DCS. You have to remember, it takes the game development world a few years to adopt new technology. Regardless, imo you always aim for stable temps and operation @ 100% cpu usage in a stress test.

Is the power management setting for your DCS profile in nvidia control panel set to "Prefer Maximum Performance?" Are you using SSAA or MSAA? @ 3440x1440 with no SSAA and MSAA 2x I get a minimum of like 80 fps in the Hornet. IMO Minimum framerate is the number you should adjust settings to, and will be more evident the closer you are to the ground, especially around areas with tons of trees or the cities with huge buildings around Dubai on the PG map.

If it IS working in VR.. you could probably achieve similar effects by disabling it and just turning up pixel density. Honestly I just flew around after setting my in game pixel density setting to 1.0 and upped my supersampling in the SteamVR settings to 200%, with msaa 2x and am quite pleased with the performance and picture quality. At least in my odyssey the guages and MFCD panels are easy enough to read after increasing pixel density. Will have to do more comparison to determine whether I like the ingame Pixel density setting or the steamVR application resolution slider better. But I'm still not sold on mixing it with SSAA. The setting absolutely kills performance on my monitor with 3440x1440 resolution. My VR resolution is already supersampled to 2019x2512 per eye and running with motion reprojection on. It's like I said.. supersampling an already supersampled image. I don't know.. I'd be interested in hearing how you feel about a higher pixel density setting without ssaa vs a PD of 1.5 with ssaa. Hard to visually ID air targets until you're close but overall feel like this is the best I'm gettting in VR. I honestly feel like a stronger VR zoom is about the only way to solve ID'ing targets at range in VR. It definitely helps in another sim I fly to have 10x zoom, where ID'ing on a monitor was much easier due to the sharper image, as well as a stronger zoom than what VR users get. That being said I've still not encountered the white box issue discussed in another thread, even when pushing my PD/supersampling above 2.0 or 200%

"Supersampling is a spatial anti-aliasing method, i.e. a method used to remove aliasing (jagged and pixelated edges, colloquially known as "jaggies") from images rendered in computer games or other computer programs that generate imagery. Aliasing occurs because unlike real-world objects, which have continuous smooth curves and lines, a computer screen shows the viewer a large number of small squares. These pixels all have the same size, and each one has a single color. A line can only be shown as a collection of pixels, and therefore appears jagged unless it is perfectly horizontal or vertical. The aim of supersampling is to reduce this effect. Color samples are taken at several instances inside the pixel (not just at the center as normal), and an average color value is calculated. This is achieved by rendering the image at a much higher resolution than the one being displayed, then shrinking it to the desired size, using the extra pixels for calculation. The result is a downsampled image with smoother transitions from one line of pixels to another along the edges of objects." You can very well think of SSAA's effect on performance in a similar regard to increasing rendered resolution. There's a reason why people using 1080P and 1440p monitors paired with a 1080Ti are having good results with it, where people running higher resolutions don't really need it to begin with, but take a much bigger performance hit than the former. Whether it's rendering more samples from pixels, or rendeirng more pixels.. it's still rendering more than just playing at your native resolution. By the way I don't use DSR or SSAA, running @ 3440x1440 which at the time pinned my 980Ti, and still puts my 2080Ti at 99% gpu usage in most cases using only msaa 2x along with my native resolution. Since then I've moved on to VR, but I'm still going to say SSAA's effect on performance mostly depends on your CPU/GPU/monitor combination. IF your gpu is more powerful than your monitor demands, ssaa will probaly be good to you, and imo is far more convenient than DSR. which I was not talking about DSR. So, with SSAA 1.5, if it's not the pixel count, what is the 150% representitive of? A pixel and a half per pixel blended together? The samples have to be rendered as something. These articles define SSAA much better than I can. http://www.tomshardware.com/answers/id-2244562/anti-aliasing-fxaa-ssaa-msaa-txaa-ambient-occlusion.html This wikipedia article explains SSAA more in depth, including the quote at the top of the post. https://en.wikipedia.org/wiki/Supersampling This article seems like a good read as well https://techreport.com/review/27102/maxwell-dynamic-super-resolution-explored and even points out that my description of increased pixel count isn't "Entirely accurate" but also states "In a very nerdy way" which to me says , this explanation works in laymen's terms for those that often find themselves in the DCS World forums speaking in terms of framerate. This article states the effect on performance is the same between DSR and SSAA. So It doesn't hurt to think of supersampling, as an increase resolution when talking about its effects on performance. I don't claim to know all the science behind it. But it makes sense to me, and my reading of these forums from people who utilize SSAA with various displays and GPU's says to me - treat it like increasing your resolution. If CPU limited - try ssaa, if gpu limited - expect a significant hit to framerate. SSAA has no effect in VR. just leave it off. And you should use either the in game pixel density setting, OR the occulus tray pixel density setting, (PD), not both. I.E. I use steamVR, in the steamVR settings for DCS I leave the application resolution or supersampling AKA Pixel Density or PD slider at 100% or 1.0 and set my in game pixel density setting anywhere between 1.5 to 2.0 depending on performance. Using both your Occulus Tray PD above 1.0 and the in-game pixel density setting above 1.0 is applying supersampling to your already supersampled image. You only need one or the other. Adjust your pixel density with one of the two options for it, leave the other 1.0 I presonally use msaa (multi-sampled anti-aliasing) 2x in VR combined with a pixel density setting that allows for no less than 45 fps when flying low or otherwise happy with the image quality.

SSAA is basically the equivalent of increasing your resolution when it comes to performance, so the effects of which will vary for users based on display type and resolution. IF you're system is CPU limited, say due to having a GPU that offers more juice than your display resolution demands, enabling SSAA could then cause you to be GPU limited, and in some cases offer better performance, or at least not near as drastic a hit to your framerate as enabling SSAA on a system that's already limited at the GPU. There's no one size fits all answer to the question of SSAA's effect on performance. If i still used my 3440x1440 monitor for simming personally I'd be happy with the performance and image quality of msaa 2x and no ssaa.

My FC3 aircraft are all bound very similarly but the only thing common about my full fidelity pits personally are my comms switches, and that's only because of SRS Radio. If SRS allowed for different profiles at the press of a button, or a dropdown menu I'd honestly love it, as reaching for a button on the hotas that doesn't correspond with the hotas in the cockpit still feels weird as crap. Personally, I enjoy matching my hotas as closely as I can to the real thing. It takes 5 minutes using the hotas diagrams from the manuals, where as trying to make a "common set" requires much more thought. From there it's all about developing muscle memory within any given aircraft. I haven't flown the A-10C in quite some time, or the harrier, but I'd be familiar with the controls in either after one sortie. Kind of like I haven't played my bass in months but if I were to go pick it up I'd still be able to play.

https://virpil.com/en/support/faq How Do I Calibrate the VPC MongoosT-50 Flightstick? Please use the VPC Configurator Light software on our website to calibrate. https://virpil.com/en/support/downloads Do not use the Windows Game Controllers calibration tool! https://virpil.com/en/support/downloads?download=19:vpc-configurator I just copied and pasted all this from the virpil website. If calibrating with the vpc configurator doesn't get you sorted i'd expect it to be faulty hardware. If you put the springs/cams on correctly and everything looks connected inside the base, and reclibrating using the VPC software, I'd imagine it's a faulty wire or connection to a sensor. Bent pins or even a miffed solder job. Stuff happens. If that's the case I'm sure virpil would want to make good on it. one of the pins on the MCU for my MFG Crosswinds was bent and creating a short, which also resulted in a brick during a failed firmware update. It made my left toe brake do crazy things at times before it bricked. Milan sent me a replacement MCU and I haven't had that issue since. Different manufacturer, but I'd imagine Virpil will get that sorted for you. I don't have a virpil stick myself, just going based off my experience with input devices in general.

Personally, I encourage people to be open minded about what's going on here. I'm not trying to speak FOR the devs, and am not a part of their team, but just offering my perspective on this. These guys chose a project that they felt confident they could complete that could provide a baseline for future prop plane projects. (i.e. wwII warbirds) I'll probably be picking it up in the future as a show of support, expecting to fully enjoy it, even if it gets limited use. I want a taste of what these guys are bringing to the plate. And this should give us an idea of what to expect from flight and engine modeling in the future, when they step up to tackle bigger projects. I have a hunch, that this aircraft is going to be on point regarding flight characteristics and other aspects of modeling. Perhaps prop planes will be this 3rd party developers new niche and DCS WWII's future will become brighter for it. Familiar the faces may be, this is a new development team offering their first entry into the DCS platform. I applaud working from the ground up like this. Creating a solid baseline that could aid future development. Showing us you have the basics covered. My experiences with this aircraft will give me a taste of what they can do, and hopefully instill confidence in future releases. I could throw $30 at supporting that. Looks like a fun flight anyway. And just imagine the sale prices in the future. edit* (I thought I posted this in another thread but it still fits )