D3D12 Missing Features

Nope. Still not possible. See this video for example (By the way, what an excellent video. seriously. why can’t there be more reviewers like this? Instead, we get worthless garbage like… this…)

Global Injection Compat. Update

SpecialK64.7z (7.6 MB)

It should be safe to use this with global injection now, any non-native overlay (i.e. RTSS or Steam) will be disabled unless you do a manual install of dxgi.dll in the game’s directory.

It’s surprising to see SK may be the only D3D12-native overlay that exists in the wild, I thought RTSS was native but it’s not. There are some performance implications there, Steam and RTSS potentially add API overhead, though how much I couldn’t say and don’t care (since I don’t use either anymore) :stuck_out_tongue:

3 Likes

I assume the overlays only gets disabled temporarily while SK is also injected? So that they aren’t permanently disabled for users?

I have no idea how to even do that :stuck_out_tongue:

These overlays disable themselves when they try to find D3D11On12CreateDevice in d3d11.dll and it does not exist (or at least that’s what I tell them).

The Steam overlay has a Windows 7 fallback (yuck) in lieu of D3D11On12, which fortunately does not exist either on any system that Special K supports. I’m not even going to bother writing code to handle that. Let it crash if anyone tries to run this on Windows 7.

Ah, that’s a nice workaround for how to force them to disable themselves.

The alternative to disable them permanently would’ve been invasive and involved e.g. denying the user execute permission on the DLL files in question.

There’s a bit of a snafu… the Steam overlay will try repeatedly to load D3D11On12, but it does eventually give up.

I don’t really know why it behaves this way:

Wed Nov 25 13:19:10 2020 UTC - CD3D11Renderer::EnsureD3D11On12Device - querying d3d11.dll for D3D11On12CreateDevice
Wed Nov 25 13:19:10 2020 UTC - CD3D11Renderer::EnsureD3D11On12Device - querying d3d11on12.dll for GetD3D11On12On7Interface
Wed Nov 25 13:19:10 2020 UTC - CD3D11Renderer::EnsureD3D11On12Device - D3D11On12CreateDevice and GetD3D11On12On7Interface not found, aborting D3D11On12.
Wed Nov 25 13:19:10 2020 UTC - Fatal: didn't get 11on12 device context
Wed Nov 25 13:19:10 2020 UTC - Fatal: m_pRealDevice is nullptr, can't continue.
Wed Nov 25 13:19:10 2020 UTC - CD3D11Renderer::EnsureD3D11On12Device - querying d3d11.dll for D3D11On12CreateDevice
Wed Nov 25 13:19:10 2020 UTC - CD3D11Renderer::EnsureD3D11On12Device - querying d3d11on12.dll for GetD3D11On12On7Interface
Wed Nov 25 13:19:10 2020 UTC - CD3D11Renderer::EnsureD3D11On12Device - D3D11On12CreateDevice and GetD3D11On12On7Interface not found, aborting D3D11On12.
Wed Nov 25 13:19:10 2020 UTC - Fatal: didn't get 11on12 device context
Wed Nov 25 13:19:10 2020 UTC - Fatal: m_pRealDevice is nullptr, can't continue.
Wed Nov 25 13:19:10 2020 UTC - CD3D11Renderer::EnsureD3D11On12Device - querying d3d11.dll for D3D11On12CreateDevice
Wed Nov 25 13:19:10 2020 UTC - CD3D11Renderer::EnsureD3D11On12Device - querying d3d11on12.dll for GetD3D11On12On7Interface
Wed Nov 25 13:19:10 2020 UTC - CD3D11Renderer::EnsureD3D11On12Device - D3D11On12CreateDevice and GetD3D11On12On7Interface not found, aborting D3D11On12.
Wed Nov 25 13:19:10 2020 UTC - Fatal: didn't get 11on12 device context
Wed Nov 25 13:19:10 2020 UTC - Fatal: m_pRealDevice is nullptr, can't continue.
Wed Nov 25 13:19:10 2020 UTC - CD3D11Renderer::EnsureD3D11On12Device - querying d3d11.dll for D3D11On12CreateDevice
Wed Nov 25 13:19:10 2020 UTC - CD3D11Renderer::EnsureD3D11On12Device - querying d3d11on12.dll for GetD3D11On12On7Interface
Wed Nov 25 13:19:10 2020 UTC - CD3D11Renderer::EnsureD3D11On12Device - D3D11On12CreateDevice and GetD3D11On12On7Interface not found, aborting D3D11On12.
Wed Nov 25 13:19:10 2020 UTC - Fatal: didn't get 11on12 device context
Wed Nov 25 13:19:10 2020 UTC - Fatal: m_pRealDevice is nullptr, can't continue.

I’ve never known a failure like that to miraculously recover on its own, and wouldn’t continue trying that every single frame the way Steam does. But what do I know? Steam runs on thousands of times more machines than my software does :stuck_out_tongue: There must be a scenario where that behavior is useful.

Death Stranding Works! thank you, The only issue with it is that if you have special K running and change any of the graphical options that the game throws an error message and crashes.

That’s strange. It’s the same engine as Horizon: Zero Dawn.

I don’t actually own that game to test on, but I guess HZD is the better of the two ports.


It’s also possible the Steam overlay is causing this. That’s a big source of weird compat issues.

The DS Port is really freaking weird, for one it runs in borderless fullscreen. let me test disabling the overlay

So guess what it is indeed the Steam overlay! Thank you :slight_smile: now I can finally fix the FPS cap.

Man, that’s going to be the death of me :frowning:

I have excellent compatibility with the Steam overlay in D3D11, 9 and GL. It’s such a common piece of software that having to tell users to disable it will get tiring. It’s funny, the Discord overlay is disabled by default and it’s the one that so far I have not had a single D3D12 compatibility issue with.

Actually DS is the better port of the two games when it comes to performance and such.

1 Like

BTW, can I get some help testing something from users w/ AMD or Intel GPUs?

I believe NVIDIA’s drivers are implementing predicated rendering wrong. According to the D3D12 spec, these two DLLs should behave identically:

SpecialK64_predicate_not_equal_zero.7z (7.5 MB)
SpecialK64_predicate_equal_zero.7z (7.5 MB)

But on my NV hardware, NotEqualZero renders the overlay and EqualZero does not.

Predication is supposed to be disabled in both, so the test condition should not affect the output. This may be responsible for the flickering in Assassin’s Creed Valhalla.

1 Like

There’s a text for it if nothing else.

Unsure if hardware GPU scheduling affects anything or not but there are differences in what AMD and NVIDIA has as best practices so what the internals look like and especially some years later and how the respective GPU company handles or implements some of this will probably differ.

Anything else for this just having it draw the SpecialK overlay then?
Easy enough to test if that’s all. :slight_smile:

Equal Zero draws.
Not equal zero has it hidden.

EDIT: Let me just check that again because I have the opposite results it seems from your reports.
That must be amazing for retaining compatibility.

EDIT: Yeah that wasn’t wrong.

Not equal zero isn’t showing the overlay, equal zero does show it when toggled.

EDIT: Should really use a less intensive area for testing and it’s also raining but eh.

EDIT: Also post-patch or whatever is causing it the temporal little things can now be observed and it’s sorta annoying ha ha.

Kinda hard to do it right in a static image but there’s this “effect” like a shimmer or flicker on a lot of elements that makes the resulting output really noisy, earlier it was mostly the edges of the SSR or simplified it was mostly observed in the water sources. :slight_smile:

1 Like

Good to know. It’s a problem with the entire D3D12 runtime then.

I don’t think this is a very common scenario (turning predication off when it was already off), but it could create some weird results if this doesn’t get fixed.


Updated build with better AC Valhalla support

SpecialK64.7z (7.6 MB)

Drawing at arbitrary framerates should now be possible without SK’s overlay flickering. I also found and fixed a few deadlock issues in Serious Sam 4. Performance overhead is lower too.

2 Likes

Control DXR + HDR


I know I said I was avoiding ugly game-specific compat. hacks in the new D3D12 codebase, but so many people have been requesting Control + D3D12 + DXR ++ HDR support that I had to add one.

Control HDR (D3D12 + DXR) Compatible Build

       SpecialK64.7z (7.6 MB)

The problem with opening the game’s menu after a save has been loaded is ‘fixed’. Technically the framebuffer should be copied and displayed behind the menu, but that was crashing because the texture the game’s trying to copy to was 8-bit color and SK uses 16-bit color for HDR. I just skipped the copy operation, so it’s a black screen. It’s a minor inconvenience, I’ll consider fixing it the right way when I have more D3D12 games confirmed working.

3 Likes

Is this for Global injection compatibility? Or still local injection?

Edit: Nevermind its only for local. I am guessing flickering effect is due to something else lol.

This one have the above fix as well you posted for Valhalla?

Was that test on AMD card?

Yeah the 5700XT though that probably doesn’t matter too much.
Just bring up the SpecialK UI and with one of the files it shows the OSD and with the other the mouse cursor jumps a bit but the OSD doesn’t display it’s invisible. :slight_smile:

The Control build has the OSD working just fine if you’re wondering about that I just got done trimming some of the older settings and fixing a few of the config parameters I had set improperly. :slight_smile:

No stability issues either but that was just a two hour session in Valhalla for now, going to see about Watch_Dogs Legion eventually and at some point Yakuza Like a Dragon but that’s D3D11 and then there aren’t too many other D3D12 titles in the backlog.

Thought Cyberpunk 2077 had gotten delayed again but it seems to still be on track for December 10th, might be something to look into but probably wait on for a few months and see how the game is on launch and what a few updates plus the big “next-gen” update will bring even for the PC version.
(Maybe get a GPU upgrade in the meantime if that’s even remotely possible ha ha.)