Switch ‘impossible ports’ are the new ‘perfect arcade’ – games built for much more powerful hardware somehow miraculously get remarkably impressive conversions on relatively meager hardware. However, variable performance and low resolution are also hallmarks of these otherwise astonishing technical achievements, and here we must highlight the work of Rebellion North for delivering some outstanding implementations. Zombie Army 4 is the latest Switch conversion, running at the same 30fps as the PS4 game at a target resolution of 1080p and keeping the title’s signature 80-100 strong zombie horde on screen. Below you’ll see our analysis work on this outstanding port, but most of this part isn’t about the ‘what’, it’s about the ‘how’, with the developer himself sharing his methodology and insights into the conversion process.
At first glance, Zombie Army 4 on Switch is a ringer for the PS4 version, and seemingly matching the resolution and frame rate goes a long way – just as it did with the firm’s excellent conversion of Sniper Elite 4. As you’ll read in the interview, development is targeting native resolution and 30fps in mobile mode on the Switch, before scaling to a docked experience. Dynamic resolution is used, with a range of 918p to 1080p, which drops to 684p to 720p for manual control. Beyond that, the clips are many and varied, but most importantly, they’re not particularly noticeable. However, there are some exceptions: reduction of dynamic shadows and no ambient occlusion of the screen space.
Tom Morgan presents this video, revealing just how close Zombie Army 4 gets to the PlayStation 4 version – while keeping the same 1080p target resolution and 30fps performance level.
The changes from here on out are more subtle. The quality of the geometry has been reduced to the far distance – with a more aggressive LOD change that is not noticeable in normal gameplay. The quality of effects such as particles and transparencies has also been reduced. Likewise for the texture situation. With only 3.5GB of usable RAM to run on the Switch, memory was a huge limitation for Rebellion’s port of Zombie Army 4. Still, the team found smart solutions. Above all, they were determined to avoid dropping a blanket across every texture in the game. Reflections are also fixed, but screen space reflections are maintained on bodies of water, supported by an improvement on Rebellion North’s existing cube map technology for Switch.
As a result, the studio’s proven track record of delivering excellent Switch implementations is only embellished with this latest release. Now, let’s find out more about how this was delivered in this interview with Rebellion North studio head, Arden Aspinall, senior programmer Alex Gray and environment artist, Reece Parinder.
To view this content, please enable targeted cookies. Manage cookie settings
Digital Foundry: What was the biggest challenge in porting a game like Zombie Army 4?
Alex Gray: To be honest, every limitation of the Switch hardware was a challenge with this one. Previously, CPU and GPU performance was a big issue, but unique to ZA4 was the pressure on memory this time around. Because it’s such a big game and there’s so much going on, we actually had to spend quite a bit of time dealing with memory. Now this is not something where you can have DRS [dynamic resolution scaling] to increase back. If you run out of memory, that’s the end. He collapses. Performance was the biggest problem though, as you’d expect, really, especially with so many zombies on screen. I mean, I think in some sieges you can get up to 80 to 100 zombies at any one time, which is really crazy, knowing how much is going on — updating all their logic and turning them into all different different passes. That’s a pretty high level.
Arden Aspinall: It took us quite a while to dial it back into memory. The way we’ve always approached Switch ports is that we want to continue to try to maintain the quality of what we’re doing in terms of resolution. And once we have that parity [with other consoles], where it works exactly how it works – no matter what the frame rate is, even if it’s one frame per second – we make it work exactly like on PlayStation. Then we can start turning the dials and pushing the buttons to try to figure out what the best compromise is that we find acceptable. But to get to this point with Zombie Army 4, we had to cram everything into memory. And even using Nintendo’s dev kits, even that was a stretch. Just getting it to actually work on the Switch dev kits with the expanded memory usually gives you an advantage. So it’s an interesting challenge.
But that meant we couldn’t see completely [picture]. It’s like climbing to the top of a mountain, seeing a whole chain of mountains, thinking, “Oh my God, we have to climb all these mountains too.” It took a long time to get to this point. And I think the team showed a lot of patience because we really wanted to start putting all the tools that we already had in the box for Sniper Elite 4 to kind of say, “okay, let’s see.” And we were kind of telling everybody, “look, wait. Let’s get it working first.” You know, we put everything we had done into Sniper 4 [into the game]. And obviously we had also done the Zombie Army trilogy. So there were some nice little optimizations we could do there. Things like shadows when they’re off into the distance rendering them lower quality and things you wouldn’t notice unless you were comparing A and B from different platforms. So we can put some of that as well [for Zombie Army 4]which we didn’t have to feature for Sniper 4 – because there simply weren’t that many enemies on screen at once.
Reece Parrinder: One of the main differences I saw on the art team side of things was that with the older games, like Zombie Army Trilogy and Sniper Elite 4 and Strange Brigade, we were kind of a GPU-focused team. We could just focus on the GPU stats that were coming in, where these really smart guys focused on sorting on the CPU side. So we end up getting them [to help on CPU]. It was the same with the memory of things. The biggest change with Zombie Army 4 was that then we had to come up with new tasks that we could help with from the outside to try to bring back some extra stuff from the CPU and memory side of things.
Digital Foundry: When you first launched Zombie Army 4, what was the state of it on Switch relative to where you ended up? What did it look like in the beginning when you just said “let’s just see how it works?”
Alex Gray: From the beginning you obviously start out just compiling the code, but after that it’s mainly about turning on the NVN renderer. So the first time it launches and we haven’t set up the render yet, you’re just sitting there at a black screen fixing the first render error. And then you just start working on the issues, implementing more parts of the render. So you’re going to start with a black screen, which is actually a huge milestone, just getting to a black screen.
Arden Aspinall: Black screen with a game running… if you’re really lucky you have the audio so you can hear the music in the background!
Alex Gray: There’s a big jump from that black screen to just rendering even the loading screen, which is just a static image. You have to have so much work: shaders to build and run correctly just to render this. So that’s another huge milestone of where we start and then eventually going into 3D. I mean, I remember seeing the zombie rendering on the front screen for the first time. This was extremely satisfying.
Reece Parrinder: I don’t know if any of you remember specific stats, but I went back and dug up some of the earliest smoke tests we had. One of the tiers for that for example – I’m not sure when that gets sorted or if it’s been a while before we get the last month’s build working. But for one of the levels, it ran at 116ms on the GPU [around 8.5fps, the target being 33ms/30fps].
Arden Aspinall: I have to mention the other thing that we were able to work through the doors, we really matched Sniper Elite 4 in terms of doing our smoke tests. The artists would find all the real hot spots around the levels and put in performance points for the programmers to hook up a bunch of performance stats where we can break down where all the cycles are going on both CPU and GPU and also where the memory is going – so it was really good. From the very beginning of the project, we could literally just chart our progress. We had like burning the task to completion, like our own drop graph to get to our magic 30 fps. So it was fun. But it’s also fun to look back on now.
Digital Foundry: Is there a stress test zone where, if you can get performance, the rest of the game should follow? Or was it mostly uniform, just testing everything?
Reece Parrinder: In the beginning when I came into the project I was thrown at the worst level, it was 160ms that we were looking at. And a lot of the things I was doing was clarifying, well, if we do everything we need to do – big batch tests like LOD reduction and stuff like that. If we can get this level down to a reasonable point, all other levels of theory should be much easier to take down.
Alex Grey: I mean some scenes where you’re going to be in a forest and the rendering of the foliage is inherently slow, just because there’s so much redraw in it. And then in other places, when you can see really, really far into the distance, you end up having to render so much. So you know there are certain sections in the game where there’s tons of greenery and it was really far away and then you had 80 zombies rendering at the same time…
Add Comment