0.11.0.50:
+ HDR Preset Default Keybinds changed to Shift+F1, Shift+F2, Shift+F3, Shift+F4
+ HDR Preset Keybindings are configurable in-game by clicking on the binding text
--
+ Unreal Engine needs to STFU when Present (...) returns DXGI_ERROR_INVALID_CALL,
it is -not- a crash and is completely recoverable by calling ResizeBuffers ().
>> SK will now lie to Unreal Engine and replace DXGI_ERROR_INVALID_CALL with
DXGI_STATUS_MODE_CHANGE_IN_PROGRESS to prevent it from self-destructing
after Alt-Tab when Fullscreen Flip is enabled.
+ Disabled %USERPROFILE% environment variable expansion in FFXV because it does
not properly handle paths containing multi-byte characters.
Interesting, guessing this continues the problems with display mode and Unreal Engine since UE3 I think but it’s nice to see some workaround possible to prevent a complete crash in this case.
EDIT: Continues to show that there are display or window management issues with this engine.
Not specific to SpecialK itself.
Yeah, there’s a reason that Microsoft kind of silently abandoned the “Fullscreen Optimization” thing This is all a compatibility nightmare and I’m crazy for even bothering.
Also Kaldaien, regarding their silent abandonment, you probably never have seen this, since I didn’t share it anywhere as people would probably create more speculation than good, but I managed to pull relatively recent info on their thoughts about it a month ago. It’s in a public discord, so all good.
(I mainly asked them due to my unfortunate time with AIR and DX9… and how they never implemented a way for air devs to work with the DWM or bypass v-sync lag through it or just engage in exclusive fullscreen / flip model)
Lastly, if we are going to speculate, this to me screams that they might be going into gaming OS direction sooner or later and finally allow a user to choose the main purpose of their OS rather than having it multi-use optimized. I would love if they added a “Gaming(casuals)” and “Competitive/Esport” setup / install for W10 in the future. One can only hope
FastSync decouples the rate that images are drawn from the rate that your monitor refreshes.
It is effectively “infinite framerate mode.” If somehow an engine can draw 30 fames in the time it takes the monitor to scan a single image, then 29 of those frames will be dropped when the monitor begins scanning the next image
FastSync disables frame queuing. Once a frame is finished, the next one just overwrites it. All other forms of buffer synchronization would hold an image in a queue until the monitor finishes scanning the previous image and when that queue of x-buffers fills up, that’s what causes your framerate to cap out at x * refresh rate.
This is why you need to combine FastSync with a framerate limiter or it just micro-stutters uncontrollably. Ideally, said framerate limiter would be simulating your screen’s refresh rate.
The net result of all of this is that V-Sync blocking is removed, and Special K adds it back This is “fame pacing” in the truest sense of the word. But it will introduce visible oddities if you try to do this to draw below your refresh rate. FastSync is only for drawing >= refresh rate.
So does that mean we only need to enable FastSync in NCP and use Flip Model in SK ? What about settings like Wait for VBLANK, Waitable SwapChain abd DWM Tearing ?
Literally none of those settings do anything if your turn on FastSync as the VSYNC mode.
Wait for VBLANK actually does still work if FastSync is enabled, but you don’t want that. The entire purpose of FastSync is not to sychronize to VBLANK.
Somewhat, though AMD has Radeon Anti Lag for this particular purpose but they work a bit differently.
You want a high GPU load overall for RAL to work at it’s best I believe not a CPU bottleneck.
And then I’m not 100% on how much of Vulkan or D3D12 AMD allows for overriding at all.
EDIT: Enhanced Sync can also still be crash prone on current drivers but I don’t think it’s entirely borked to where it crashes to a unrecoverable black screen GPU shutdown anymore.
(AMD Virtual Super Resolution or VSR should also be fixed since possibly back with the 20.2.1 drivers now I’m having a hard time to keep track of it all both fixed and pending or open issues.)
EDIT: Well AMD has both E.Sync and Anti Lag whereas NVIDIA rolled a few options into a single setting with multiple options I suppose is a bit more accurate.
EDIT: Far as AMD and reducing one frames worth of lag I think you can get the same by flip model and the new SpecialK settings and with more control over the various settings involved, pretty sure there’s a limit here and if the game engine and settings allow for it you can hit that already.
(Whereas the AMD on/off approach bounces between good for a GPU limited workload and not as good if it’s a CPU limited one.)
EDIT: Guessing the higher latency adjusting options from NVIDIA is similar in approach as well but maybe the lower settings without enabling everything and toggling certain overrides can be beneficial with less drawbacks.
(No removal of render ahead frames or such.)
If I click Low Latency mode in Advanced section Rendered Latency frames bumps up to to 1 and 2 but with that off and other settings on I got pretty almost solid 0.
Hmm interesting. When I alt tab out of BG3 and go to my second monitor it locks FPS to 30 in menu. Or during video intro it locks it to 60. That’s a bit odd?
Wasn’t there some multi monitor issue going on but then the new cumulative update comes out on Tuesday so if it’s anything resolved as part of the current .540 patches for 19041 and 19042 that will hopefully be resolved and then the rest of the 20H2 improvements when the enablement package goes live for everyone.
Activates a bunch of stuff and installs Edge Chromium complete with annoying helper popup like back in the browser choice days. Wonderful.
EDIT: Back to the original issue though it looks like 2004 / 20H1 already has the multi display fix included so nothing with a newer cumulative or needing 20H2 for this improvement to take effect.
