Fixed the performance issue, but no controller input still.
Does it work without Special K?
Wonder if disabling X or Direct input hooking might help, could be something with the DS5 and the Steam client / Steam client beta way of supporting it though compared to the other controllers since it appears to be a bit different?
Could also test the Steam input or big picture input options if disabling some of this recovers the performance for figuring out what is interfering at least.
EDIT:
There’s abunch of categories for this in SpecialK.
[Input.Gamepad]
AllowHapticUI=
DisableRumble=
DisablePS4HID=
DisabledToGame=
EnableDirectInput7=
EnableDirectInput8=
EnableHID=
EnableNativePS4=
[Input.Steam]
UISlot=
[Input.XInput]
Enable=
PlaceholderMask=
Rehook=
SlotReassignment=
UISlot=
EDIT: Wonder if it’s the new haptics?
AllowHapticUI=false then perhaps?
Although “feeling” the SpecialK UI should only apply with the SpecialK UI active should it not?
Suppose enable to false, disable to true and allow to false could clear all of it, DS is a Direct Input so I don’t believe the X or Steam options do much although Steam would wrap it either through Steam or X Input AFAIK.
Option OCD so AllowHapticUI should be either Disable or Enable instead of Allow. 
(It’s not very important at all though. Ha ha.)
Was using an ASI loader mod, seems like it completely messed up controller input, was also missing rumble on Xbox controller due to it. Case closed.
That sounds like a handy feature. I’d love to be able to block input to games that use SteamInput. They don’t work like normal games, the Steam client does all the input processing. I really can’t say a single good thing about SteamInput, I’d like to kill it every time I see it in a shipping game.
Tested again, I lose controller rumble when running SK and native input without Steam.
You can disable SK’s use of the input APIs of the gamepad:
In this case it’s probably related to the Raw Input bug that Cyberpunk 2077 had. The Cyberpunk Engine Tweaks mod included a fix for that which was necessary before CDPR fixed it properly in the v1.05 patch I believe.
The Raw Input bug broke all form of virtual input – including those of Steam Remote Play, Parsec, and many others.
Edit:
Here’s the original code with the bug:
Did anyone manage to get Kingdome Come Deliverance to work with Special K? As soon as I try launching it with SKIF enabled, the game just crashes back to desktop 
Try a local install instead.
20.12.29
========
+ Added support for switching between D3D11/D3D12 on-the-fly in Serious Sam 4
>> Should assist with D3D11On12 and Ansel compatibility in normal games that
don't support this bizarre render API hotswap feature
+ Fixed framerate uncap in NieR: Automata
20.12.28
========
+ Disabled auto-update checks on all game-specific plug-ins built-in to SK
SpecialK64.7z (7.7 MB) SpecialK32.7z (6.5 MB)
5 Likes
Lovely as that engine is I am curious if the API was ever designed to work in that way but somehow it apparently does. 
Guessing there are some downsides though or there would be less of this dual binaries or exiting and starting the program again to switch which I presume is a lot cleaner.
(And makes other programs go ??? a bit less as to what just happened presumably. )
EDIT:
D3D11On12 is what I expected most current D3D12 titles to be relying on if not coded explicitly only for D3D12 with no D3D11 code or interop how it’s called code so that should help overall compatibility from the sounds of things. 
Overlays and what not too as another improvement.
I stare at a lot of disassembly, and all I can say is WTF is any of that? Those pseudo-variable names, comments on branches on variables I don’t see declared or used anywhere. That’s meaningless trash
More details:
I had a feeling it was something to do with raw input so this looked promising. Loaded the game in IDA Pro which is a very popular disassembler/decompiler and is what’s seen in my screenshot. Checked if the game used GetRawInputData and it did - once. I looked around the code where it was being used with the decompiler so I don’t have to read assembly. Saw another call to GetRawInputDeviceInfoW nearby and googled it - GetRawInputDeviceInfoW function (winuser.h) - Win32 apps | Microsoft Learn
Game seemed to be using this function to determine if the current raw input event processing from WM_INPUT is either keyboard or mouse. Used x64dbg again to break on this and noticed the function was returning an error and the game wasn’t handling it so the game didn’t determine if it was keyboard or mouse and stopped handling the event. Still don’t exactly know why, but the HANDLE GetRawInputData was returning which was being passed to GetRawInputDeviceInfoW is zero / invalid - causing the bug. Then on the msdn docs I noticed the RAWINPUTHEADER returned from GetRawInputData already contains the info to determine if keyboard/mouse - RIM_TYPEMOUSE 0 / RIM_TYPEKEYBOARD 1.
So I noticed they never had to use GetRawInputDeviceInfoW in the first place. The hex change just makes it ignore what was returned from GetRawInputDeviceInfoW and instead use the info already obtained from GetRawInputData via pretty basic x86 assembly knowledge.
1 Like
Hahahah, yeah. The whole thing is so silly. You just look at the header to know where the data comes from, not the freaking device that generated it, lol. Talk about inefficient.
That little ‘Raw Input’ red/green light that blips when there’s input on kbd / mouse would have very high overhead if it were doing anything more than just looking at the header as the game processes RawInput.
In any event, this game doesn’t use SteamInput, so none of this matters to me There’s still no way to block input to SteamInput (since it’s not even hosted in the same process as the game is), so games that use it will always register mouse clicks and keyboard input and other obnoxious things when SK’s control panel is in use.
Making matters worse, Valve disables XInput when a game turns on SteamInput. So I can’t use my gamepad to interact with SK.
I want to murder SteamInput.
2 Likes
Is there a page that we visit to always get the latest SpecialK64.dll or we just need to wait for your post?
Wait for post. Usually those uploaded dll’s are for testing and not intended for the public.
1 Like
For now it’s either this topic or the D3D12 status topic but it hopefully won’t be too long until 0.11.1 is available directly as a download over the existing version.
Alternatively the Discord channel and discussion can also see new build posted.
EDIT: Ah and yeah it’s kinda like a beta or work in progress so there’s a few builds here and there.
Far as I know it’s always compiled against the latest code and changes so no separate branches or specific variants for compatibility or testing of some specific issue or game but just the latest code overall rolled out and less tested and more experimental.
EDIT:
Isn’t Proton or something open to where one can look into and route the Steam Input API should there be a need to hook that and set some options for?
Or would that have to go through the Steam client, Steam overlay and such. Hmm guess it would be outside of the game process as mentioned at least and nothing to do with the Windows OS functionality like XInput since it’s custom.
EDIT: Speaking of gamepads I wonder what SpecialK does with AMD ReLive in that regard, it’s a custom XInput XBox gamepad I think but I don’t use ReLive so it’s little emulator thingie is not something I’ve investigated.
One of those things added in 20.5.1 so it’s been there for a while.
(That and the also forcibly installed OpenVR driver and feature set tends to be mysteriously removed after driver updates. ~ )
ReLive and the overlay is something I tend to stay away from, I preferred the older modular process but at least it can be handled with some tweaking.
(Same as with NVIDIA though don’t remove or clean out something that another actually useful or important part of the driver or something the user wants to utilize outright requires or things break.)
EDIT: Should check on that widget too come to think of it.
GCN
RDNA1
RDNA2
All differ a bit with ADL and AMD’s lack of documentation or providing info early enough or to smaller partners and such.
Guessing general sensor data should work but specifics like the fans won’t be picked up if there’s any monitoring for those in the GPU and other widgets.
I’m sorry, but what does that mean exactly?
Installing Special K for the game alone, and not using global injection. See the below page on the wiki:
2 Likes