Talk:The Last of Us Part I

Okay, I've sent about 7 hours testing graphical settings on an RTX 3070Ti in The Last of Us part 1 PC and I've figured that replacing the default DLSS 3.1.1 with DLSS 2.5.1 showed greater temporal stability than even the games native TAA. DLSS 3.1.1 is great but the temporal stability isn't that great even DLSS 3.1.2 suffers from the same issue. Now with DLSS on quality at 1440p I'm able to use High environmental textures, High character model textures, Object textures to low, effects textures to low and rest all on Ultra without crashing anymore and the VRAM usage is down to 7.4 GB instead of the ridiculous 10GB on native

Now the game runs at 80+ FPS without problems

I assume performance is the same between these three DLSS versions at same upscaling quality-modes right? VRAM usage going down when using DLSS is normal, as the whole game and its effects are rendered at a lower resolution and then upscaled. I assume there is no noticeable difference regarding VRAM when looking at DLSS 3.1.1 vs 2.5.1 right? And what signs of temporal instability do you see in case of using DLSS 3.1.1 DLL from the game vs DLSS 2.5.1 DLL drop-in replacement? So, in what ways does 2.5.1 seem to improve the situation compared to 3.1.1?

Not the first occasion that 2.5.1 performs better than 3.x.x @Johnhitman2194 can you check with dlss-tweaks which profile dlss 3.x.x is using?

1x anisotropic filtering is basically no anisotropic filtering. So that's an option to disable it.

Sorry, it is still some form of AF, even if it is minor. So still sadly no way to FULLY disable it :( So, if we want to stick to the facts, then the note is currently correct.

No, it's not. The number there is by how much the sampler increase the number of texture fetches along an axis in case when the polygon isn't parallel to the screen - which is what AF does. 1X means that there is no increase and thus no AF.

https://developer.arm.com/documentation/102449/0100/Texture-filtering seems to suggest otherwise. As I'm not 100% sure, I'm asking this in the PCGW Discord :)

Asked it in the PCGW Discord's #articles channel and it indeed still applies AF: 1x (8 texels), 2x (16 texels), 4x (32 texels), 8x (64 texels) and 16x (128 texels). 1x thus does not equal Off and the game allowing only 1x as the lowest value with no option to turn it completely off thus warrant the "always on" value here. Regarding texels: "A “texel,” or texture element, is the smallest unit within a texture map." (https://www.intel.com/content/www/us/en/gaming/resources/what-is-anisotropic-filtering.html)

It's the same as off. AF 1x gives you the same filtering as just bilinear because it doesn't increase the sampling of blf/tlf - hence why it's "1x".

You can test it yourself instead of asking some Discord channels: https://nvworld.ru/utilities/aftest/ - here setting AF 1x is exactly the same as using linear filtering for minification.

As Mrtnptrs said, AF 1x does not equal Bilinear. Just because you can't see the difference between bilinear and 1x AF, it does not mean there's no difference.

What? If you can't see the difference then there is no difference. It's that simple. And AF 1x equals no AF (whether that means bilinear or something else depends on other texture filtering settings). Here's Unity docs stating this very clearly as an example: https://support.unity.com/hc/en-us/articles/210606003-How-does-the-Anisotropic-Textures-Quality-Setting-affect-each-texture-s-Aniso-Level- Here's another Unity related discussion which state this as clear as possible: https://forum.unity.com/threads/making-sense-of-anisotropic-settings.797085/ Don't make things up, please.

I think the sources you provided are Unity's internal-settings-specific and not talking about AF as a whole. But to make this fully clear, I took images of the exact same scene (right after loading a save game to have exact same character and camera position) of in-game 1x AF vs 0x AF forced through the control panel. I see a very very minor difference: the 1x-ingame seems to have a very minor difference/improvement regarding texture filtering compared to 0x-forced. Still, this difference is extremely minor, which is to be expected. Hopefully this answers your question.

Ok, I'll try one last time.

"A texture's maximum degree of anisotropy is specified independent from the texture's minification and magnification filter (as opposed to being supported as an entirely new filtering mode). Implementations are free to use the specified minification and magnification filter to select a particular anisotropic texture filtering scheme. For example, a NEAREST filter with a maximum degree of anisotropy of two could be treated as a 2-tap filter that accounts for the direction of anisotropy. Implementations are also permitted to ignore the minification or magnification filter and implement the highest quality of anisotropic filtering possible."

"...For example, a NEAREST filter with a maximum degree of anisotropy of two could be treated as a 2-tap filter that accounts for the direction of anisotropy..."

Which means that a degree of anisotropy 1 (1x) is equal to 1-tap filter - meaning that there is no supersampling happening and thus no anisotropic filtering.

https://registry.khronos.org/OpenGL/extensions/EXT/EXT_texture_filter_anisotropic.txt

"A maxAnisotropy value of 1.0 or lower disables anisotropic filtering."

https://developer.apple.com/documentation/scenekit/scnmaterialproperty/1395402-maxanisotropy

Now as to why you see differences between in-game 1x and CPL forced to no AF is a different matter. I'll take a look at the game a bit later.

According to all official listings including Steam the standard version of The Last of Us Part 1 doesnt contain the "Left Behind" story expansion. Only the Deluxe Edition does among with cosmetics and early upgrades and it is wrongly listed on the page under "Version Differences"

I only own the Standard Edition and have access to the Left Behind chapter. The wording on the store pages is just weird. The standard edition thus already includes this prequel chapter.

Added a user ref to that version differences note to better explain as the wording is indeed confusing; another editor here on PCGW was also confused by it.

So you can confirm that if I get the standard edition of TLOU on steam I also get the Left Behind prequel story?

"I only own the Standard Edition and have access to the Left Behind chapter." So, yes :) Just the store listing that is weird. But fully understand the confusion....

I just wanna be extra sure given the price difference and the fact that it has released with extremely bad performance

Haha, no worries, I understand. Also, if you buy it you can always quickly ask for a refund, so you wouldn't really have to worry anyways :)

Hey guys, was browsing a few steam discussions and there's a potential fix for all the listed problems (in the title) which is the oo2_core9_win64.dll file (compression library found in the root file of the game) that causes all of them, it seems the game is using a buggy version of that library causing memory leaks, long Shader compilation issues and transversal stuttering, here is the official website of the library: http://www.radgametools.com/oodlehist.htm

Game is using a buggy version of it, i tested out the fixed version with my Rtx 3060 and Intel core i5 12450h, and i gained 10-20 more fps and performance is more stable

Before applying this tweak/during first gameplay (reports seem to be very vague and inconsistent, hence why it hasn't been added to the PCGW page yet), did you make sure to let the shader compilation finish before starting playing the game? Because otherwise your perceived performance improvement after applying this fix could be simply from the shader compilation progress having finished, it thus not having to compile shaders asynchronously in the background and thus improve performance during gameplay.

I compiled the shaders before even touching the game, this dll file was tested after 3hrs of gameplay

Ok, nice. The FPS is quite variable in-game, did you then benchmark the same sections? Because of all the hype around this fix online, I just want to rule out it just being a perceptible improvement influenced by others saying it works. Not saying that is the case of course, just wanting to rule it out. Especially because people say it is using 2.9.6 version of the library, while the file contains zero version info, so how did people know. Have the feeling they simply assumed from http://www.radgametools.com/oodlehist.htm "fix : Data : fix memory leak in certain cases for Optimal2+ compression levels introduced in 2.9.6 (rrPool leak when allocation was attempted from scratch arena, but failed and fell back to user allocator instead)". If there is a memory leak, it could very well also be in another library. People claiming after applying this fix that shader compilation takes only seconds, tested myself to be false, isn't helping the reliability of these claims either.

I'm not necessarily thus saying it is not true, but missing version info for the dll file in question (But people on Reddit still making claims about it, seemingly based on Oodles' changelog and users suspecting a memory leak, so almost looks like they are blindly blaming Oodle, cause could also be somewhere else, who knows.), the "fix" turning up already like an hour after launch, the false shader compilation claim etc. make it all sound quite sketchy to me and some other editors I spoke with on the PCGW Discord. Also, do you have a link to the Oodle library file you replaced the game's one with? Then I can do some specific testing myself :)