The Last of Us Part 2 Remastered: how the PlayStation game was ported to PC
By Recently, The Last of Us Part 2 was launched on PC, introducing the second segment of the well-known Naughty Dog PlayStation saga to a wider audience. Porting specialists Nixxes have built upon the groundwork laid by Iron Galaxy for Uncharted 4 and The Last of Us Part 1 on PC, delivering new designs and familiar boundaries in almost equal proportions.
We recently engaged with several key figures from Naughty Dog and Nixxes regarding the efforts they put into this port, which launches in a significantly improved state compared to its forerunner. These individuals include Naughty Dog’s programming director Travis McIntosh, game director Matthew Gallant, and a group of developers from Nixxes: PC product director Coen Frauenfelder, lead optimization director Wessel de Groot, junior graphics engineer Yana Mateeva, and senior director of development and studio head Jurjen Katsman.
As usual, the interview below has been slightly modified for clarity and conciseness. Enjoy!
When did the project for The Last of Us Part 2 on PC commence? What are the origins of this release?
Travis McIntosh: It was over a year ago, likely a year and three to four months ago, and originally Nixxes was not available. We had always planned to collaborate with them, but initially, we worked with Iron Galaxy to create an initial PC version. During the fall of last year, Iron Galaxy transitioned out, and Nixxes joined the project. We underwent a three to four month transition period after which they effectively took over as the lead developers around October, becoming our primary partner, and they handled the bulk of the technical work. We communicated consistently—at least once a week, often three times a week or more. Most of the technical details were managed by them, while we oversaw their progress, saying things like, “Hey, fix this. Fix that.”
What are the foundations of the Naughty Dog engine on PC? It operates on DirectX 12, but it must have existed in some earlier form. Did any part of it exist on PC prior to the porting process, like a live editor, or did it need to be developed from scratch?
Travis McIntosh: Clearly, the development of The Last of Us Part 1 for PC was beneficial for this project. However, if you’re asking whether we started entirely from scratch before we even had a PC version, the answer is that there was hardly any PC code. When we develop PlayStation games, we essentially work as low-level as possible—close to the hardware—and focus solely on one platform. So there was very little PC support in the project initially. Everything had to be adapted for Part 1 on PC, and then for Part 2, we had to make further adjustments with Iron Galaxy’s assistance. Once Nixxes joined, they began on the engine work during the transitional phase of porting what we had developed for Part 1 to Part 2. The engine didn’t change significantly between these projects, so many of the lessons and expertise we gained from Part 1 were transferred to this project.
From Nixxes’ perspective, what were the significant modifications you aimed to implement from Part 1 to Part 2?
Coen Frauenfelder: Well, certainly, we’ve established our own approach to doing things here at Nixxes. We aimed to carry over much of the knowledge we already had, ensuring that the game runs smoothly and performs well. We closely examined what was already in place, and building on that, we contributed a lot of our own work. It took some time, but our experience was invaluable.
Travis McIntosh: I want to highlight something they accomplished that was truly impressive—the current PSO [shader] compilation system in this game as opposed to what we had in Part 1 on PC. That was entirely Nixxes’ expertise, and I believe it significantly enhances the experience in this game.
That leads us to our next question. Could you briefly explain how the new system collects and compiles PSOs and how it varies from the previous system?
Wessel de Groot: In terms of collection, it’s quite similar. We simply let QA test the game and gather the PSOs. However, the new system does not perform any pre-compilation in the initial menu—everything is handled in the background during gameplay. The initial loading screen waits for all PSOs to gather, and once that’s complete, the loading screen proceeds. Those are the key aspects of the new system.
How do you effectively balance the load between compiling shaders in the background while maintaining smooth frame-rates and performance during gameplay?
Wessel de Groot: We aim to minimize PSO threads in the background while gameplay is ongoing and conduct the process as non-intrusively as possible. Moreover, if PSOs are not ready in time, we skip that phase and simply raise the priority for that PSO collection. In the next frame, hopefully it’s completed, and then we can really display the object.
I’ve noticed thread usage spike after a cutscene, which I assume is PSOs being processed in the background. Does this happen every time following a cutscene, or what prompts it?
Wessel de Groot: It’s based on streaming. So when any new content is streamed in, then the PSO compilation begins.
That’s interesting, as we’ve observed similar usage spikes when transitioning between locations—often around 20 seconds of processing in the background when entering a new area on a lower-end CPU. Another change is the addition of dynamic resolution scaling; what was it like incorporating that?
Yana Mateeva: Oh certainly, it was once quite appealing. The precise engine was well-suited for implementing dynamic resolution scaling to a fair extent. Therefore, on that note, it was not an overly wide stimulating experience, and it functioned reasonably well. We encountered some difficulties with visual outcomes, which we needed to adjust specifically for PC to ensure they paired effectively with dynamic resolution scaling. But yes, that’s part of the process.
What other game libraries, aside from dynamic resolution scaling, did Nixxes contribute to this project?
Coen Frauenfelder: We introduced several! We’re now utilizing DirectStorage, so we have our own libraries for that, which significantly aid in overall game streaming. Additionally, all game inputs are processed through our systems, including those going through various upscalers.
Could you elaborate on the modifications to streaming regarding DirectStorage?
Coen Frauenfelder: Absolutely, the framework is highly compatible with DirectStorage. We’re exclusively utilizing CPU decompression rather than GPU decompression. The new framework provides us various advantages—more space, improved scalability for streaming issues, resulting in faster performance.
Jurjen Katsman: One thing to possibly mention is that we’re using a variety of compression algorithms that decompress rapidly with low CPU usage, yet they consume slightly more disk space. We aim to reduce reliance on unloading and decompressing in the background, so we face various trade-offs compared to PS5.
During SIGGRAPH 2020, there were presentations on low-level work with PS4, but concerning PC with features like Shader Model 6, you use web wave intrinsics and asynchronous compute. Is the game utilizing any of the more “low-level” techniques that are possible with DX12?
Wessel de Groot: We are employing async compute and wave intrinsics. I’m not entirely certain how it specifically compares to Part 1, as I did not participate in that one.
Jurjen Katsman: I think it’s important to note that while some of these techniques exist and can be utilized, they don’t necessarily level the playing field with the PS5. In fact, using async compute on the PS5, where hardware specifics and compatible features align well, we have consistently found that it’s notably more effective on consoles than on PC, regrettably.
Travis McIntosh: It’s just exceptional on PS5; there’s almost no gap between us and the hardware. We all understand what we can achieve, and we can get our command lists and simply send them off, which gives clarity about what will occur. Kudos to Nixxes for figuring out how to manage what could unfold on 100,000 different configurations.
Returning to PSO compilation, in previous ports, there was a lengthy shader burn for each aspect of the game that could load. Even in the Uncharted games, switching between Uncharted 4 and Lost Legacy would cause the PSO compiler to restart. Where does the abundance of PSOs originate? Does the game simply acquire additional shaders, or is it specific variations from elements that may not be clear?
Travis McIntosh: There is no PSO loading or compilation on PS5, so the way we designed the engine allows artists the utmost control and flexibility to make the game look its best. Artists can adjust shaders on a very detailed level, and as a result, we have significantly more shaders than we would if we were creating a PC port from scratch. So it’s a diverse range of variations, and that has always been the case. I believe that with Nixxes’ handling of it, it’s quite seamless for most users.
It’s a remarkable difference; loading chapters and entering the game is significantly quicker. Are PSOs the primary factor in load times?
Jurjen Katsman: We have some internal figures, but yes, a substantial portion of loading time is attributed to PSO compilation, so loading for the second time is greatly reduced. The PC version may load significantly faster than the PS5 version, depending on your system.
So concerning challenges, you mentioned the variety of shader variations, but