I mean in other modules like in the F-16, Squawk codes that are set in the virtual cockpit can be used with stuff like LotATC
I donât know how I feel about this one. My HOTAS doesnât have any more room for more commands.
Oh yeah!
This was a Big Help for Freeze ups and Stutters in MTâŠ
Looks like so far the fix isnât fixing. Iâve been disabling core 8 using the âaffinityâ tab in Task Manager and thatâs cured the problem.
Does any of this stuff work for AMD processors? I donât appear to be having stutters, but am CPU bound in MT no matter what DCS settings I am using. TIA
From what Iâve read on the DCS forum, the issue seems to be predominant on 12th Gen Intel CPUs.
I see that too, but itâs explained by the frame rate limits set by me and the VR driver.
Just played with the Mudhen JDAMS and theyâre stupid easy, at least for PP attacks. Havenât tried TOO with the TPOD yet.
Interesting. The plot thickens. Funny that in single thread mode, the CPU has not such limitation.
I have a 12700k and a 3070 and I donât really get any issues that Iâve noticed in 2D.
The only thing Iâve noticed this week is an intermittent white frame in F2 external view. It happens every 5-10 seconds I would say. Doesnât happen in the pit.
Watching the plane fly along and a single frame will be all white making it look like there was a flash of sun glint or something in your eye.
I havenât flown much at night so I donât know if itâs there.
I will add Iâm using Win11. If you have an Intel 12x00 or newer, you better either be using Win 11 or disable the E-cores in the mobo BIOS. Win 10 doesnât know how to handle them and I got stuttering in EVERYTHING.
As I understand it, itâs not really a CPU limitation, itâs a limitation of the measurement or display.
Letâs say, for example, that your CPU frametime is 9 ms, and your GPU frametime is 11 ms, total frametime 12 ms.
GPU limited, right?
The sad part is that this is about 80 Hz, just too slow for the 11.11 ms needed for 90 Hz. If your headsetâs next best framerate is 60 Hz (16.66 ms), âsomethingâ will have to wait for 4.66 ms before the frame can be shown. That âsomethingâ counts as CPU time according to the DCS CPU/GPU limit display.
Thus from the actual frametimes to the measured values according to DCS, we shift from GPU limited to CPU limited, by adding the 4.66 ms waiting time to the CPU frametime.
Framerate | CPU | GPU
80 Hz | 9 ms | 11 ms
60 Hz | 13.6 ms | 11 ms
This means that when flying in VR, DCS displaying âCPU limitedâ could mean one of 2 things:
- Your CPU is taking longer than the GPU to be finished with the frame and is thus limiting your framerate
- Your entire machine combined is rendering much faster than the nearest lower framerate that your headset supports, such that the waiting time for the headset is longer than how long your CPU is waiting for your GPU.
Yeah OK that last sentence is a mess, I hope the example above it with the numbers is clear though.
Why not in single-threaded?
(Wild speculation)
In single thread mode, it is probably easier to separate âCPU is doing something usefulâ from âCPU is waitingâ. Since in multithreaded async code, there is often some thread waiting for some other thread: either because it needs a result that the other is calculating or because it wants access to a shared resource which can only be accessed by one thread at a time. Or something else entirely, IDK, Iâm not an expert at parallel programming.
Thanks Freak. Thatâs a really excellent explanation of the correlation between refresh rate, CPU, and GPU performance. Well, at least as far as my tiny old brain can comprehend. I guess thatâs why everyone strives for 90 Hz or better, even though the Oculus default is 72 Hz.
I know that the times that I raise the refresh rate in the Oculus software, I do get occasional stutters. Maybe thatâs why stutters are often reported and why I donât seem to have them. I keep the refresh rate on both the Q3 and Q Pro at 72.
Thatâs a great explanation @Freak!
I tried BIGNEWYâs hybrid Intel fix and couldnât tell the difference. I then killed core 8 again and saw a sudden improvement.
Are you guys noticing the ghosting a bit more in this update? The effect that looks like vapor or smoke is coming off another aircraft?
Itâs a known issue with TSAA, DLAA and DLSS. I havenât noticed anything getting worse but itâs definitely there.
Freak knows! Good explanation, man!
Does this happen with certain modules? I had this happen to me only with the Apache so far, and it always happened at a very specific point in one of my replay tracks.
Has anyone figured out how to get rid of the giant squares? I should say âgiant squaresâ for me in Quest 3 VR. Apparently for others, the new visibility dots are a positive change. The autoexec.cfg âfixâ does not work. The squares are hideous. Itâs as if the DCS world has become populated by the spaceships from the film âArrivalââŠ
Apparently this has been fixed. I just need to find the box to tic. Moving onâŠ
Well, not moving on. The âImproved Visibilityâ tic does nothing, checked or unchecked. Big squares everywhere!
5 Cores or 24 cores,
If everyoneâs maxxing out settings and using more resources than their system has, the problem doesnât go away by limiting the cores to 5, youâre simply delaying the problem by forcing the sim to load everything slower, once everything is loaded youâll have the same problem. Meanwhile everything is being rendered with lower mipmap textures for 5-10x longer.
Itâs like your V8 has a Fuel Pressure Problem so Cylinders 6 and 7 are mis-firing and causing your car to stutter. So you flip that switch and put the car in Eco Mode and shut off 4 of the 8 cylinders and think you fixed the problem.
Itâs not a solution, it does clearly highlight the issue,
Putting everything on max will eat even the highest end resources.
Iâll sound like a broken record, but seeing as I get dozens of requests for help and every one always has their settings way to high for what they want to do in the sim with the hardware they have.
I donât know how many times the opening reply from someone was âI have a 4090 graphics settings shouldnât matterâ