Talk:Atomic Heart

Both User:Yobson and I have tested the game over on the Discord and failed to note any presence of actual mouse acceleration in the game.

It would seem that some users are mistaking the abnormally high mouse sensitivity for mouse acceleration.

The solution is to turn down the mouse sensitivity by like a ton. On my 250 Hz 1600 DPI mouse, I had to turn it down to 15% to get anything close to regular movement, and I imagine users with higher mouse polling rates needs to turn it down even further -- probably using both the X and Y axis sensitivity sliders on top of the general mouse sensitivity slider the game has.

In the page's history I can see that User:Mrtnptrs has removed edit(s) which provide a fix for the game's mouse acceleration.

The user removed this information because it is "included on the UE4 glossary page linked below the video table".

The only information on the page about mouse acceleration now states "Forced on by default, with no way in-game to disable it." which while "technically" true is not helpful to players in any way when a solution exists.

I **strongly** disagree with this. This is the polar opposite of good practice.

The average visitor is not going to see the "UE4 glossary page."

The average visitor is not going to assume that the UE4 glossary page contains mouse acceleration fixes.

The average visitor is not even going to know that the UE4 glossary page exists, or is relevant to this game.

At the time of writing, there is a comment on a Reddit post with 183 upvotes which **directly expresses confusion at this page** because of the reasons I listed above: https://old.reddit.com/r/pcgaming/comments/117ypip/psa_for_atomic_heart_use_this_link_to_learn_how/j9esksk/

As far as I know User:Mrtnptrs is NOT a moderator or an admin on this site.

Therefore I'm going to restore the changes because they clearly, objectively provide value to readers.

seems pretty silly to remove it, when i have an issue with a game i usually search it up here on pcgamingwiki first to find the fix since that's what i've come to expect from the site. that's what i did when i was looking for a fix to begin with and then searched google since it wasn't on here and found a steam guide on how to fix it, at no point did i think about checking the UE4 glossary page for the fix. once i found it i came back here and added it so others who do the same as me and come check here first can easily find it only for it to be removed 20 mins later.

Also explained it here already: https://www.pcgamingwiki.com/w/index.php?title=Topic:Xd1clvgav2sc3tlr&topic_showPostId=xd1clvgav6qebxjz&fromnotif=1#flow-post-xd1clvgav6qebxjz "Those mentions should be removed as stated already: those fixes are already included on the UE4 glossary page linked to under the Video table. This has been agreed upon and discussed many times in our Discord. Please go there to dispute this decision if you disagree." Fixes already included on that glossary page should not be included again on the page as it is a literal copy. I can't help sadly that someone linked to it. It is the PCGW normal way of working to not include it againn on game pages. If in disagreement, please take it up with the higher-ups in our PCGW Discord.

Mouse smoothing isn't the same as mouse acceleration. They're somewhat related but quite different in what they deal with.

I'm downloading the game myself atm to take it for a test spin and will make the necessary changes to the page when I have done so.

As it stands though, the supposed fix of using bEnableMouseSmoothing is unlikely to actually remove mouse acceleration since, well, acceleration != smoothing. And PCGW doesn't actually track/cover the presence of mouse smoothing. This is generally because it haven't often been deemed a major concern and some in fact prefer it over not since it removes minor jittery mouse movements from affecting overall aim.

Anyway, we'll see where we land once I have been able to test the game out myself.

To quote the Soviet hero of the game: "what a godamn clusterfuck".

I most like the very weird "Squirt your polymer inside me" quote haha

Both User:Yobson and I have tested the game over on the Discord and failed to note any presence of actual mouse acceleration in the game.

It would seem that some users are mistaking the abnormally high mouse sensitivity for mouse acceleration.

The solution is to turn down the mouse sensitivity by like a ton. On my 250 Hz 1600 DPI mouse, I had to turn it down to 15% to get anything close to regular movement, and I imagine users with higher mouse polling rates needs to turn it down even further -- probably using both the X and Y axis sensitivity sliders on top of the general mouse sensitivity slider the game has.

With Game Pass version 1.3.3.0 (released on 26/02), you can just delete the intro video file to skip it.

Already stated on the PCGW page indeed: https://www.pcgamingwiki.com/wiki/Atomic_Heart#Skip_intro_videos

Ow wait, you mean you can also just delete it without issues, hmmm, let me try it

Can reproduce it, thus overhauled the skip intro fix into just removing the files; replacing it with a empty file was a bit weird and probably totally not needed. I added you as a user source for the GamePass version if that is ok? :)

Thanks for testing it and letting me know :)

If anyone else has been having stuttery distant animations (despite having anims set to max), it looks like it's to do with "ah.Quality.TargetFPS" cvar, changing to 0 seems to get rid of all the stutters/low-framerate issues with them for me at least.

You can change that in the UE4 dev console, the pak from nexusmods.com/atomicheart/mods/1 can enable it for you, then open console with ` or ~ and enter "ah.Quality.TargetFPS 0" (without quotes) while at main menu to set it.

Sadly adding cvar to INI or editing games settings file didn't make it stick, only way seems to be entering it in dev console each time you launch atm (dev console does save what you entered though, so you can use the arrow keys to select it from history instead of typing it each time)

Hoping maybe a .pak to change this could be made eventually...

---

Another method which did work with INI was here previously (using "ah.significance.enable=0"), but while that also helped with some stuttery anims it also reduced framerate of a bunch of them too, which TargetFPS didn't have any issues with, so seems entering the TargetFPS cvar each time is the best option atm...

There's now a QoL Tweaks mod which should be able to set this cvar for you automatically: nexusmods.com/atomicheart/mods/22

Was about to add a section to main article but noticed some users did report certain anims were breaking with that unfortunately... I played for a while using cvar change and never noticed any broken anims with that though, so not sure if it's an issue with how that mod works, or maybe certain setups just don't work well with TargetFPS stuff being changed.

Source: not me, but MacProTips on YT was able to launch it in Parallels: https://youtu.be/LDKkgfc5LHg

Parallels supports only 11_1 feature level, so the game must be falling back to that.

I'm not in-depth knowledgable of Parallels, but if they support the Direct3D 12 API then the game would still use it, albeit as you say at a lower hardware feature level. Ergo, still technically "DirectX 12" (since D3D12 is not a part of DirectX 11).

Our d3d version rows track Direct3D API usage — not DirectX usage. Hardware feature levels like 11_1 is how the newer Direct3D APIs retain backwards compatibility with older hardware.

I assume that's probably what happens here -- the game uses DirectX 12 while having backwards compatibilitity with DirectX 11-level hardware (most DX12 games tend to have this).

Ah, I see. Looking at dxdiag right now - that's indeed how it is.

Sorry, I'm new to graphics programming. Thanks for the explanation :)

Nvidia's marketing term "DLSS 3" is irrelvant and should be forgotten. DLSS Super Resolution (aka the upscaling tech of DLSS) has reached v3.1.x and "DLSS 3" no longer refers or suggests that frame generation is being used in a game. A game that uses DLSS v3.1.x or newer is fully capable of not having frame generation as a result.

Our upscaling row deals with the super resolution part — not frame generation part. The version of the frame generation DLL files (still quite low at like v1.0.3 or something) is also irrelevant.

Edit: DLSS v3.0 (or "DLSS 3") have also been removed as an acceptable value in PCGW's upscaling field.

The game is using DLSS v3.1.1 Super Resolution SDK and DLSS v1.0.3 Frame Generation SDK.

"DLSS 3.1" is not a thing.

There's only "DLSS 3" - which is a marketing package containing DLSS SR, FG and Reflex SDKs. All three have their own versions which aren't at all related to the marketing name of "DLSS 3" tech.

It is a bit confusing.

No, you have DLSS 2.x that is the Super Resolution part and DLSS 3.x is the Frame Generation part. I know it is majorly confusing, sorry, Nvidia has caused this.

No. Frame Generation has its own versioning and Super Resolution SDK version is 3.1.1 at the moment.

I've checked a couple of other games with DLSS 3 support, and this seems like a common issue which should be fixed before it has become too widespread.

My suggestion here would be to use something like "DLSS 3.0 (SR 3.1.1, FG 1.0.3)"? If we want to provide such details - these SDK versions will change with patches and with DLSS SR own OTA updates which is the main feature of SDK 3.1.

It may be better to just use DLSS 3.0 - although I'm not sure that this is a correct name either as all Nvidia materials on it call it "DLSS 3", not "3.0".

Only now DLSS 3.1 is mentioned indeed. See https://discord.com/channels/165183350913499136/326048443040530432/1077644303570051112

Frame Generation is not tracked for DLSS, the Super Resolution (aka upscaling) is - as it's the main target of using DLSS.

NVIDIA calls it "DLSS 3" as it's the easiest to market.

As for the technicalities, DLSS 3.0 never existed, but 3.1 does, as shown here: https://github.com/NVIDIA/DLSS/releases/tag/v3.1.0

Not sure why FG isn't a target for using DLSS suddenly - you can use it with native res for a "free" performance boost and the IQ impact is arguably even less noticeable than from using SR.

DLSS 3.1 doesn't exist either. There's DLSS Super Resolution SDK v3.1 (your link is for that) but this isn't the same as "DLSS 3.1" - which presumably would be an upgrade over "DLSS 3" as a whole, not just a new version of SR SDK.

I'm not even sure that there will be DLSS 3.1 tbh as at this point Nvidia seems content on providing upgrades to DLSS 3 components (SR, FG, Reflex) without bumping the DLSS 3 package version at all. I expect DLSS 3 to be just DLSS 3 and then maybe there will appear DLSS 4 or something.

Reflex is not a DLSS component. DLSS is Super Resolution at heart, with Frame Generation being an ***addition***.

Reflex is a DLSS 3 component. There is nothing "at heart" of DLSS 3. It's a bundle of tech now. You can't call it "DLSS 3.1" because that wouldn't be accurate - only SR resolution component is at version 3.1(.1) right now.

@Dgrdsv still thanks for bringing the issue at the beginning to my attention as it made me realize that adding 2.x version to the game page was a mistake and that the DLSS version number should indeed be 3.1 :)

I'd still suggest rethinking this for all titles with DLSS 3 support at least. It is very possible that SR SDK will reach v4 or even higher prior to there actually appearing "DLSS 4". Using either generic "DLSS 3" moniker or going with something like "DLSS 3 (3.1.1/1.0.3)" seems a lot more robust for the future.

In the gamepass version of the game, there are no saves along this path. \AppData\Local\AtomicHeart\Saved Hence the question where are the gamepass\msstore saves and whether they can be transferred to the steam version.

The location of the save data in the gamepass version is %LOCALAPPDATA%\Packages\FocusHomeInteractiveSA.579645D26CFD_4hny5m903y3g0\SystemAppData\wgs\<user-id>

In each randomly named folder, there is a file with no extension, so if you name the file something like 0.sav, 1.sav, it might work for the Steam version.

Despite the developer's confirmation last month that Atomic Heart would support FSR 2.0 (https://wccftech.com/atomic-heart-final-q-fsr-2-confirmed-old-consoles-will-be-fine/), the game seems to only offer FSR 1.0, at least on the Game Pass version.

Can anyone confirm if this is the case on the Steam version as well? Is it perhaps coming with the raytracing update?