Awesome. The developer read the community discussion on DRM and has decided to remove the system from their game.
It’s unfortunate how this often works, a first-time indie developer adds DRM to their game because that sounds like a sensible thing to do to protect your investment, but quickly learns that DRM kinda favors the bigger publishers. Thankfully, most small developers are paying enough attention to their community to get the picture and this is a mistake that often quickly goes corrected.
The build I released yesterday with a ton of things disabled to make that other DRM game work… now allows SK to run in uPlay DRM games. I’m beginning to wonder why I had those features enabled by default?
Interesting, whatever these things are/were and what they benefit from being enabled against some of these sensitive software getting all restrictive about it.
SecuROM might be a bit optimistic but it’d be nice if it actually worked for that too.
EDIT: Crysis 3 isn’t 64-bit?
Thought they had that as a extra for Crysis 1 but 64-bit was the default going forward.
Guess not.
(Well I suppose it fits with Crysis 2 also being D3D9 initially and then updated with D3D11 later on.)
Meaning Ryse would probably be the first 64-bit only Crytek game then.
EDIT: Guess I’m just going to be keeping this recent 64-bit DLL for Legion and Valhalla though just in case.
Tried the new dll. Injustice 2 still requires Silent=True to make it stop detecting SpecialK as a debugger.
Edit: Tested Dragon Age Inquisition. It appears the new DLL has solved the input widgets bug. I’ll test more Frostbite games to confirm.
Edit 2: Issue seems to still be there with Anthem.
This is ‘disabled’ SecuROM, mind you. It doesn’t have any DRM functionality enabled so its just randomly complaining about SK being a ‘debugger’.
You’d think CryTek would be on the forefront of the 64-bit adoption seeing how Crysis 1 shipped with both 32-bit and 64-bit executables, but no, neither Crysis 2 nor 3 are 64-bit for some reason.
Yeah it took some searching but it seems I am remembering it incorrectly and regardless of edition there was only ever a Bin32 folder.
Crytek changed a bit or maybe it’s also down to the publisher, SDK and a level editor and shader source files for the first game.
Level editor for the second game.
Nothing at all for modding and file encryption and stricter DRM for the third game and on.
Crysis 3 still has a good tech progression to it and the D3D11 update for Crysis 2 is pretty forward even.
Still a curious omission as the game should be out around the time when a larger shift to 64-bit was happening with Windows 8 and newer having a stable OS with mature drivers and also far as hardware goes 4+ GB of RAM being more common.
DRM wise the tools here would also have been focused more on X86 for at least some years more.
EA could have done a lot better but at least the new director and management aren’t entirely against re-releases, remasters and not everything needs a online bit as some mandatory included thing.
(Also as more recently revealed through Ubisoft’s issues some of their recurring elements were also pushed for heavily by some of the upper creative directors and leads.)
Remains to be seen if Crytek will outsource Crysis Warhead, 2 and 3 possibly Ryse giving it the same overhauling the re-release of Crysis 1 got targeting Switch and then the other consoles and PC.
Haven’t checked up on how that’s been received and supported since that prior patch info, I assume it’s the usual and it’ll be supported but Warhead and others likely hinge on sales more than anything.
(One way to get rid of the SecuROM stuff at least if EA doesn’t or won’t update the existing version which was also a problem back with the older days and lack of support once a game was off active maintenance.)
Yeah, I’m considering what the appropriate design should be…
Turning off all of these debug-related features severely impacts the amount of unique information that SK can provide in logs and in the thread widget. Since realistically there is no down-side to SK’s debug / reverse engineering core except in the case of DRM, I’m of the mind that this stuff stays on by default and users can deal with bad DRM on a case-by-case basis?
I’ll probably just make a config setting for minimum-debug mode. That does, unfortunately, give off performance vibes as debugging usually means slower, and SK’s debug features are designed to improve performance. No idea how to phrase this in the cfg. file to prevent users from turning debug stuff off for all the wrong reasons :-\
I have included 32-bit and 64-bit builds with Special K’s debug layer disabled. Logs, thread performance profiling, some game-specific plug-ins and API hooks that rely on GetProcAddress (…) are all going to break by disabling SK’s debug features and I don’t know the full scope of issues that will be created by doing so at the moment.
This update serves only to benefit compatibility with DRM that detects some of SK’s code and thinks there’s a debugger and then refuses to let your game run, do not expect a performance increase or anything like that.
As soon as I figure out the scope of DRM affected by this, I’ll make it a config setting. Possibly different levels of debug functionality can be retained without triggering DRM-panic mode.
Also tried it with red dead redemption 2 Epic store version and it loads now lol. with others version there was an authentication error. But UI doenst render correctly
Good news is that the DRM compat. update properly got Special K into Crysis 3, in both local and global injections. So SecuROM isn’t whining any longer.
Less good news is that the game only seems to render an entirely black screen with SK injected (in all types of injection). I dunno why right now, but I’m throwing darts at it to see what sticks.
Dunno if it’s any helps, but here’s the logs and config file I used for Crysis 3. This is with the Steam and Origin overlays gently disabled through their client settings.
Don’t do that, don’t even alt-tab out of a Vulkan game that Special K miraculously is working in (unless it’s using DXVK). The whole thing of getting SK to apply to Vulkan HDR games is an incredibly fragile hack that has no business even working You MUST leave a Vulkan game in its initial state after Special K finds its way into the render chain, any attempts to change graphics settings in-game or alt-tab, will fail disasterously.
I have no interest in spending any time on alternative APIs for HDR at the moment, I’m tied up in a lot of image processing I wrote that will only work in D3D11.
As for the black UI issue, that’s entirely different. I re-wrote the shader I use to draw my overlay in HDR, but I only did it for the high-quality scRGB framebuffer format. Most games with official HDR support do not use scRGB, they use that inferior HDR10 format (which I grow tired of even having to write code for).
Black UI in HDR10-based games can be fixed w/ SpecialK64.7z (7.6 MB)
To be honest, you’re better turning off offical HDR in any game that needs that, and instead using Special K’s HDR override. I do HDR image processing with much more precision than these games do.
