Kaldaien have mentioned wanting to move over to a year/month version numbering scheme instead of the current one. If it included the day as well it’d be easy to tell exactly how up-to-date a specific copy is.
Currently the way most of us separate day-to-day versions from one another is by using the ‘Date modified’ timestamp on the DLL files.
The ‘Date modified’ timestamp will basically be the timestamp when Kaldaien compiled that particular DLL file, so it’s easy to tell how old a specific DLL file is.
Would imagine a incorrect parameter or issue with D3D12 would be a lot worse compared to D3D11 which can already take out the display driver even with AMD and NVIDIA doing their thing to prevent this.
(Or the OS being able to gracefully recover from a lot of this even if it means restarting the display driver.)
Can’t really tell what breaks though but 1.05 has it’s issues, the SMT fix is only partial and at least one quest about some “Johnny” is now broken as a NPC was removed.
In addition to whatever else is going on with the code, hopefully CD Project can eventually turn it around but they’re under a lot of pressure now I would imagine from investors and such even if the stock was kinda inflated this backlash was probably worse than expected.
(They had to have had some expectations for how poorly the old-gen console builds would be received at the very least.)
Try deleting the cache found at:
%LOCALAPPDATA%\CD Projekt Red\Cyberpunk 2077\cache
And redo the settings in your game. Apparently each time you change settings in graphics you need to delete the file in there and such so game has it compiled correctly. Some ppl claimed their crashes stopped after deleting that file and verifying files.
@JonasBeckman
“t least one quest about some “Johnny” is now broken as a NPC was removed.”
Is that the one where you get his clothes and car?
Not actually sure the way I heard it is I believe it was somewhat like this for a user post about the 1.05 update and the state of the game “The Johnny quest is now broken after this update and you are locked out of the better endings to this quest because one NPC won’t spawn.” I am still clearing some older and some way older titles on the backlog first.
It works perfectly fine in D3D12 now. It’s just third-party overlays that don’t work, I generally like to have some control over their brightness after making your game HDR, but can’t do that in D3D12 yet.
I tried to convert 2077 SDR to HDR, but no matter the settings, the output was broken.
By overlays you mean things like Steam or RTSS?
I run the game from the .exe without Steam running.
Am I missing something, or has anyone else gotten SDR to HDR conversion working. I’m talking about running the game in SDR, not the scRGB HDR passthrough.
From my understanding, SK requires the game to run in HDR. Sounds like supporting SDR->HDR in native HDR-aware games introduces compatibility issues and whatnot elsewhere.
Don’t know if it only applies to D3D12 but Kal broached the topic yesterday on the Discord:
The issue is that the game is physically turning HDR off the correct way, and SK’s supposed to honor that. The SDR->HDR feature’s only supposed to be fore HDR-unaware games.
Hacking my way around this to turn HDR back on after a game turns it off is going to break stuff.
As far as I know, with the exception of achievement popups and text OSD, D3D12 support is basically finished, tested and gets the Special K seal of approval.
Unless someone can find a compatibility problem w/ a D3D12 game, this will probably be promoted to release by the new year. (If you want to help break it, I suggest Ubisoft games, they never work right and are a good acid test).
I’ll add text OSD support in later, I really want to get this out the door.
Haven’t tested these new 27’s / 28th’s here but so far it’s mostly worked really well, bringing up the UI doesn’t do much for these last few builds for D3D12 compared to the earlier pre-25th I think versions (The older versioning numbers not the new date ones.) but the functionality is still there and that’s the important bit.
AC Valhalla which is D3D12
Watch Dogs Legion also D3D12
And Immortals Fenyx Rising which is D3D11 and just continues working as usual.
The games can be a bit unstable at times if you aren’t too careful but that isn’t due to SpecialK there’s just a lot of little issues that can trigger an exception the online state in particular seems really flaky often timing out or disconnecting but it’s not too much of a hassle.
(Breaking as intended I suppose? )
Mostly tuning the FPS limiter and the various graphs and helpers for how to set all that up optimally.
Wonder how much of a wrap it’s possible to get into here, dgVoodoo2 from D3D9 to D3D12 and then that into SpecialK less for SK though and more like what DXVK does due to AMD and performance quirks ha ha.
EDIT:
RDNA2’s not bad but it has the same shortcomings but also the same solutions for it.
(Shelve the old code much as is possible and run it all on D3D12 or Vulkan by what means this can be accomplished by. )
+ Fixed uPlay Overlay Support in D3D12
+ Fixed UE3 infinitely shrinking windows when removing borders
+ Disabled Haptic Feedback unless using Gamepad Input in the control panel
+ Alt+F4 Capture only provides a confirmation dialog if the game would
otherwise block Alt+F4 functionality, or SK's control panel is open.
+ Fixed Mouse Input Capture in Dying Light
+ Added Screenshot Sound
So now we’re one step closer to solving the UE3 D3D9 32-bit stuttering issue?
I highly recommend troubleshooting that particular issue with Life is Strange running in window mode.
Without SK injected the intro logos are animated and the main menu renders at the same frame rate as the refresh rate.
With SK injected the intro logos aren’t animated at all and the transition between them is abrupt as the actual displayed image updates like 1 frame per 2 seconds or so. The main menu background also stutters its way forward despite an otherwise smooth frame pacing according to Special K.
What’s interesting with Life is Strange is that it’s the exact same issue that Mirror’s Edge experiences, but doesn’t affect the mouse nor Special K’s widgets. This makes it a bit less painful to experience than Mirror’s Edge, where the game runs fullscreen exclusive and where everything is affected making it hard to interact with the game at all.
Mirror’s Edge is a earlier build though customized, windowed might work from setting the config file if even that’s unavailable from the in-game settings but borderless was added later on and even then not every UE3 title using the newer versions supported it.
(Overriding might be possible but with the existing Unreal Engine issues it may not be recommended currently until this is resolved.)
Don’t have too many UE3 games at the moment, King’s Quest I think is somewhere in the backlog folder and then Hat in Time + Expansion.
Whereas in the Unity backlog folder there’s a little bit of everything from 4.0 to 5.0 and then 2018 to 2020.1 builds. Those early ones are going to be interesting and likely a bit more problematic compatibility wise.
2008 - 2009 for Mirrors Edge 1 I think, not the oldest but it’s back there with some of the earlier ones back as major updates followed the Gears of War developments from Epic.
(All sorts of improvements landing in the engine code, engine eventually wasn’t all brown and bleak looking ha ha.)
)