I’m not the greatest at explaining but there’s two of these one disables Steam related logging to the “logs” folder and the second disables the Steam related functionality itself although there are other options for inputs but these relate Direct and X input gamepad functionality and then some few options for completely disabling mouse or keyboard input which isn’t going to be of much use if you want to actually use these devices.
Personally I think the options could be renamed to be a bit more clear as to their purpose instead of having the same named setting in two sections.
(EDIT: Although the GUI and OSD naming might be a bit clearer, I should actually use that more instead of the ini file editing.)
But that can always be done later on.
Was thinking there was a partial support or implementation for all of the various Steam API functionality but there’s always the possibility that the mod author went the extra length and actually hooked up everything even if it would have been simpler (Going by Kaldaiens post above.) to just utilize Direct Input 8 (DInput8.dll) as the entry point and .dll file to load this through.
(Thus why it breaks or conflicts with SpecialK which is worked around by forcibly disabling Steam API enhancements entirely.)
EDIT: The setting is a bit of a brute force approach or catch all for troubleshooting purposes, better if it can be enabled but sometimes it’s useful to have although ideally it’s best to keep this as there’s quite a few functions depending on having this working.
Some non-Steam games might also still have this file included which can be problematic and one case where disabling this becomes useful without losing any actual Steam functionality since it’s not going through the Steam client.
I can’t stop playing it. I see much of the Witcher 3 playbook on it, and it didn’t fell on the ubisoft open world pitfalls.
And while the game is RPGish, you can compensate levels with skill or preparations.
There’s going to be another patch next week so maybe that will help but unless HZD was affected by the driver issue causing a few games to when they run the primary render thread at a higher priority I don’t think this driver will change anything far as the stuttering is concerned though it may improve stability if there are undocumented changes or tweaks which is usually the case.
(The prior hotfix already resolved that same issue as well although this driver has a couple of additional improvements on top of what 451.84 had.)
Not entirely sure actually, post I took it from was made yesterday but linked to the general Steam hub for the game and the search system isn’t the most effective but I assume it’s next week and the patch is going through final testing.
And there’s a new post as I was typing this so it looks like it’s going to be this week then, nice!
Hopefully the game can get fixed up over the next couple of weeks in regards to the primary memory and overall stability issues and with more time also get further optimization and additional fixes.
This game reminds a bit of the Arkham knight port, that Kal miraculous fixed many things.
Consoles uses some kind of unified memory in which CPU and GPU memory are all the same.
This game uses all 7GB VRAM com my GTX1070 and 10GB (of 16GB) RAM. I don’t see that many ultra quality textures for it to use all of that.
My assumption: This is a direct port from the console touching the less possible on texture streaming.
I’m curious how it runs on GPUs with less than 7GB VRAM or systems with only 8GB RAM. Minimum requirements says: Nvidia GeForce GTX 780 (3 GB) , X for Doubt.
I feel lucky because , I have a very very old cpu and with SpecialK helps, the games runs ultra-smooth at 30fps.
I would think they at least cache or allocate some 70 - 80% of the available VRAM thus why the game looks like it’s using anything from 4 to 12 GB depending on the GPU and the memory it has.
Not sure what it does with RAM though, leakage aside where it just can keep building up over a short period of time when it does work as usual (best it can?) it varies just as much but it’s not filled up or cached it seems and it just fluctuates a lot far as I can find from reading up on how the game performs so even systems with 32 GB or more can have some varied usage whatever the game is doing.
Would have really liked a texture pack too improving on some of the assets particularly also normals and specular maps which would have helped some of the assets like the robots and NPC although terrain and other objects still hold up plus Alloy of course.
(I tend to be sensitive to blurry texture details though but it’s understandable that not everything can be 2048x2048 sized or bigger either ha ha.)
EDIT: Although how much does the game actually needs that’s a interesting question, would think 4 GB shouldn’t be a issue the engine is super aggressive with culling and even has pop-in although some of it might be from the PC port and how it handles memory and when it clears and loads in data which it seem to be doing pretty much constantly so I don’t know how much it retains or tries to keep as a sort of minimum cache if anything.
Texture quality should correspond to actually reducing mips too so it’s not just a cache value like some other games or game engines or a combination of both.
PS4 and I’d imagine the PS4 Pro version probably does much the same, better hardware allowing it to hit a higher base resolution particularly when it’s still going for a 30 FPS target.
Which just leads to the question if the developers could fix the timing to allow at least a stable non-problematic 60 alternative with supported but less tested higher or uncapped.
(It does at the moment but a lot of stuff just breaks, input like mouse hits some negative acceleration, effects don’t work at all and things like hair physics just stop.)
EDIT: Now that’d be a fine change.
Use DLSS / AM DLSS ( well whatever they might use if they even attempt or can attempt it, not an easy thing to match.) throw it into the upcoming console generation of hardware and end the 30 FPS target and coding practice replacing it with 60 and 4-kinda instead of 4k now achieved through upscaling.
Actually the person on that page claims the games version is older than the one he is linking. In the comments it shows how he knows this.
The dxcompiler version coming with the game and found within the 1.0.2595 folder [Horizon Zero Dawn\Tools\ShaderCompiler\PC\1.0.2595 ] seems to be build from 1.5.1911.0 @ SHA|commit d0e9147ab86c8cb29a5fd81bd758e44d440c332c
Original Horizon DX Compiler
REPORTED version: 1.5.0.2498 (HEAD, d0e9147a)
ACTUAL version: anything from 1.5.1911.0 @ 2606 27 Nov 2019 to 1.5.2003 2615 4 Dec 2019
Then he found a newer one that seems to fix other issues as well.
The following DXIL unverified artifacts on mine setup actually build the shader database faster then any previous build. The whole compilation seen as optimization screen within the game take around 2/4 minute.
The frame pacing (latency) is also more consistent but mine current VGA VRAM reach an memory threshold duo the way the game handle or not-release some disposable resource.
–
The following DXIL is sort of partially reviewed seems to -enable-16bit-types. The build time for the shader database is longer and resolve some, if not all, of the disappearing stuff going on NVIDIA. More testing is required. Unfortunately some object will still randomly disappear for a fraction. An higher tier of setting can eventually reached on NVIDIA card without too much frame sacrifice.
Apparently it’s a compile of the source data but the version number doesn’t match up and it doesn’t seem to match CRC wise with the compiled version checksum which you would have expected them to use from one of the various Windows (10) SDK builds and release stable runtimes and distributions.
So the file could be from the end of 2019 to the later release candidates for the mid 2020 versions.
Plus there’s the built compiled version from the source data which I didn’t find the link to but that’s version 1.5.0.2771
Yep, wonder how some of these things happened though the Github repository is just one part and then there’s the actual former DirectX SDK now the full Windows (10) SDK also including D3D.
Interesting that it can be replaced at all, wonder how much it helps and how much it risks breaking plus the 1.5 version is still some WIP pre-release.
But it seems to work at least.
Also seems changes to the driver settings can break the games pipeline cache file so deleting that can fix stuff like seemingly non-working anisotropic filtering and corrupt or glitchy shader effects.
(Although from info about it the compiler itself might have some issues if updating this to a newer build seemingly helps resolve this if the cache itself wasn’t damaged or corrupt in some way before.)
So I am testing the latest test build. The 1.0.3523 one and it seems to build Shaders Compilation process much quicker. Normally the original took like 30 minutes or so. this one is already hit like 20% in about the time I wrote this lol.
Well the older version usually took close to 10 maybe 20 minutes. But it was a crawl.
Edit:
Should point out I am AMD using an RX 5700 XT as my card so lets see how much improvement this does to game.
Edit2: Did Benchmark and Did Ultimate Settings at 1440p. Interesting results. The whole benchmark had very minor stutters / Hitches.
When before I did custom settings a bit different. Might redo benchmark with those original settings I used.
Edit3:
Well this got interesting the settings I used prior which is a bit lower in some areas gave me lower score lol. Well lower than my last Benchmark. But on side note tons of hitching and stutters during benchmark.
well whatever they might use if they even attempt or can attempt it, not an easy thing to match.) throw it into the upcoming console generation of hardware and end the 30 FPS target and coding practice replacing it with 60 and 4-kinda instead of 4k now achieved through upscaling. 
