Bethesda and MachineGames’ Wolfenstein 2: The New Colossus is one of the most eagerly anticipated upcoming games at the moment; presuming you are going to play it on PC, you probably want to know whether or not your machine will be able to run it. The Wolfenstein franchise, much like most other id Software properties, has a history for being graphically and technically intensive. The New Colossus looks no different in that regard.

You can check out the full recommended and minimum requirements for the PC version of the game below. You can also check out the range of settings that the game will apparently let you configure and tweak. It sounds like this will be an excellent PC port- which is just as well, since the franchise was originally a PC franchise to begin with.

Finally, Wolfenstein 2 executive producer Jerk Gustafsson has confirmed that the PC version of the game will also support the Vulkan API. “We’re also taking full advantage of Vulkan, allowing us to push improved performance across the board in ways that simply weren’t possible before,” he said. “The minimum hardware requirements are set to ensure a high-quality experience, and with Vulkan players should see solid performance on a variety of system configurations. However, if you’re aiming for 1080p with high framerate and settings, you would need to bump towards our recommended specs.”

Wolfenstein 2: The New Colossus launches on the PS4, Xbox One, and PC on October 27. A Nintendo Switch version will follow in 2018.

Minimum Requirements (720p and 60 fps at low settings) 

• CPU: Intel Core i7-3770/AMD FX-8350 or better
• GPU: Nvidia GTX 770 4GB/AMD Radeon R9 290 4GB or better
• RAM: 8GB
• OS: Win7, 8.1, or 10 (64-Bit versions)
• Storage: 55GB

Recommended Requirements (1080p and 60 fps at high settings)

• CPU: Intel Core i7-4770/AMD FX-9370 or better
• GPU: Nvidia GTX 1060 6GB/AMD Radeon RX 470 4GB or better
• RAM: 16GB
• OS: Win7, 8.1, or 10 64-Bit
• Storage: 55GB

Settings

• Lights
• Shadows
• Directional Occlusion
• Reflections
• Decals
• Motion Blur
• Image Streaming
• Volumetric Quality
• Decal Filtering
• Deferred Rendering
• Chromatic Aberration
• Depth of Field
• Resolution Scaling

DirectX 12 and Vulkan are supposed to be the wave of the future for PC gaming- that’s what we’ve been told. But while the two APIs continue to be engaged in a fierce battle for supremacy, uptake on them by most developers has been… slow, to put it bluntly.

So when we had the chance to speak with Brad Wardell, CEO of Stardock – who you may remember as one of the most vocal proponents of DirectX 12 – we made sure to ask him why developers aren’t using it and Vulkan all that well. According to Wardell, the lack of support right now comes down to the newness of both APIs, and the ensuing lack of documentation on properly exploiting them- but for both of them, widespread adoption is only a matter of time.

“DirectX 12 and Vulkan are certainly total game changers because they allow multiple threads to be talking to GPUs simultaneously,” he said. “It’s as simple as that. DirectX 11, no matter how fancy your engine was, only one of your threads could talk to the graphics engine at a time. And that was better than DX9, where only one fixed thread could talk to an engine at a time.

“But DirectX 12, if I have 8 or 16 cores, and all of them can talk to the engine at once- then that’s a hell of a performance boost. That was actually the reason I got a lot of scepticism about the benchmarks for Ashes of the Singularity, because we came out and said we are seeing a 400% boost in performance on an eight core machine. And when we shipped it, it ended up being even bigger than that. People thought the numbers were crazy, but think about it, they’re not. If in DirectX 11, only one core can talk to the GPU at once, and in DX12, we have eight- your theoretical limit would be eight times a boost. We don’t really get that, but a four times boost is not that crazy then.

Given how game changing these two are, the only reason they are not being supported right now is a lack of documentation, according to Wardell.

“The biggest reason is documentation. With DX11, there’s lots and lots of books out there for it. DX12 needs a lot more documentation before people will pick it up. The other thing is, people are now using off the shelf parts. And so, that can be tricky because if you have multiple threads talking to the graphics adaptor once, you have to be careful how those threads work, you can’t just- if you have two threads talking at once, your apps will crash. It’s actually quite tricky to do it right. And so because of that, it’s just slow going. I can say that Microsoft is doing some pretty exciting stuff on that end- but whether, in the long term, it’s all going to be DX12 and Vulkan, because you can’t just walk away from something like this. Wait until 16 core CPUs are the norm, if you’re using DX11 at that time still, you might be at 1/10th the speed of a DX12 game. That’s impossible to ignore.”

Given that multi-core CPUs are a wave of the future, and something that are only going to get more and more prevalent across all product categories as time goes on, it is only a matter of time before developers have to contend with programming for them. Given that, Wardell may be right- it will only be a matter of time before they are forced to come to terms with either DirectX 12, or Vulkan, or both.

The Khronos Group have confirmed that Nintendo’s upcoming Switch system will officially support their next generation Vulkan API, in addition to OpenGL 4.5 and OpenGL ES; the updates come to us via their official website, where the Switch is now listed as an official ‘conformant product’ for all three APIs (via WCCFTech).

Vulkan API support in particular should come in handy for developers- Switch will apparently see a major hit to its GPU clock speeds when it is undocked, which means developers will need access to all the power and juice that they can get. A low level, highly efficient API like Vulkan might just be what the doctor ordered in that case.

The Nintendo Switch is currently due to release worldwide in March 2017; exact details about the system, including specifications, a lineup of games for the launch and beyond, price, release date, and more, are currently unknown, but should be revealed come January 12, when Nintendo will be hosting an event to officially take the wraps off of Switch.

Unity have announced that the Unity Engine, the most popular engine used for independent game development, as well as for development on PC and mobile platforms, not to mention the engine officially endorsed by Sony and Nintendo for development on their systems, now supports the Vulkan API, the open source competition for DirectX 12, right out of the box.

The feature is currently still in beta – it is available in the new Unity 5.6 beta update to all Unity users, including Personal Edition users – but Unity are still claiming 60% performance improvements already. “Vulkan is a new generation graphics and compute API that provides high-efficiency, cross-platform access to modern GPUs on desktop and mobile platforms,” Unity said, speaking of support for the API. “It’s designed to take advantage of multiple CPU cores by allowing multiple threads to run in parallel. This means increased speed with reduced driver overhead and CPU workload, leaving the CPU free to do additional computation or rendering.”

Vulkan is the big new addition, but Unity 5.6 also adds improvements and enhancements for existing graphical tech, including Metal Compute, Particle System and GPU Instancing. What does this mean for you, the average gamer? It means that a lot of your games, no matter what developer they are from, and what platform they are running on, now have a chance to look far better than they used to.

Microsoft’s DirectX 12 appears to be the next generation PC gaming graphical API of choice- which makes sense, given the ubiquity of Windows when it comes to PC gaming, and DirectX’s deep integration with Windows. That said, however, there are now alternatives to DirectX, viable alternatives that developers could be using, and open ones, rather than closed proprietary solutions like DirectX is- such as Vulkan.

But possibly because of Windows ubiquity, and because of all the hooks that DirectX has with Windows, or maybe because of all the other pushes for DirectX adoption that Microsoft have made, such as the aggressive push for Windows 10, or bringing DirectX to Xbox One, the fact remains that more and more developers are supporting DirectX 12 over Vulkan, or any other alternative, for their PC games- and this is something that Axel Gneiting, engine programmer at id Software, doesn’t necessarily approve of.

Speaking on Twitter, Gneiting said that developers using DirectX 12 over Vulkan ‘literally makes no sense.’ Elaborating on his stance, and in response to some questions, Gneiting pointed out that with Windows 7 forming a major chunk of the PC gaming market, and with DirectX 12 being incompatible with Windows 7, using DirectX in an attempt to have ‘one codebase’ makes no sense, since developers would need to create two separate ones anyway. He pointed out that the argument that programming for Xbox One and Windows 10 becomes easier by using DirectX 12 is moot too, because DirectX 12 on Windows and on Xbox is very different, necessitating two separate code paths anyway.

He also made some observations about how a lot of the perceived benefits of DirectX 12 are not exclusive to it, noting that both Vulkan and DirectX give similar performance benefits anyway.

I guess my question here is- if that is the case, why does it bother him at all that DirectX is the preferred code path for developers over Vulkan? I suppose there is something to be said for pushing open solutions like Vulkan, over proprietary and closed ones like DirectX, which effectively trap developers in Microsoft’s development ecosystem, so I can see some of his reasoning. But then, I suppose that DirectX benefits because it is not open- it has Microsoft to evangelize it, because Microsoft have a vested investment in seeing it widely adopted. Vulkan being open by definition has no such custodian, and that is why there is no one to pitch it to developers to the extent that Microsoft do with DirectX.

I'm really getting annoyed by everyone adopting DX12 instead of Vulkan even for PC exclusives. This literally makes no sense.

— Axel Gneiting (@axelgneiting) July 1, 2016

@nlguillemot Availability is now not an issue anymore, you will need two code paths on PC for Win 7 compat making the Xbox stuff invalid

— Axel Gneiting (@axelgneiting) July 1, 2016

@nlguillemot Wider HW support? How so? HLSL is the only valid point I can understand

— Axel Gneiting (@axelgneiting) July 1, 2016

@nlguillemot @Isaboll12 This is complete FUD. Vulkan on Windows 7 has no higher driver overhead than on Windows 10.

— Axel Gneiting (@axelgneiting) July 2, 2016

@nlguillemot @Isaboll12 GPUs have virtual memory. All samplers into one giant desc set, index it by push constant, done.

— Axel Gneiting (@axelgneiting) July 2, 2016

@nlguillemot @Isaboll12 Memory residency is managed by WDDM. Page table is updated by driver, virtual addr stays the same. Problem solved.

— Axel Gneiting (@axelgneiting) July 2, 2016

@nlguillemot @Isaboll12 Mantle btw also supported bindless and this worked just fine on Win 7. Don't buy all MS propaganda.

— Axel Gneiting (@axelgneiting) July 2, 2016

@kenpex @baldurk @nlguillemot Fermi isn't supported with DX12 either, Intel Vk drivers are coming

— Axel Gneiting (@axelgneiting) July 2, 2016

@kenpex @baldurk @nlguillemot Xbox needs special path anyway. Xbox DX12 is not Windows DX12. At least not if you want full perf.

— Axel Gneiting (@axelgneiting) July 2, 2016

@AndrewLauritzen @nlguillemot @Isaboll12 I didn't argue that, I'm just saying that perf benefit of DX12 and Vk is massive even without it.

— Axel Gneiting (@axelgneiting) July 2, 2016

With Vulkan now officially coming to mobiles, and with Unreal Engine 4 already being available for mobile devices, with mobile devices getting higher end graphic chips and performance components with each passing month, thanks to Qualcomm, Intel, and Nvidia, high end performance on your smartphone and tablet is no longer an alien concept- after all, we already have iPad games beginning to resemble Xbox 360 and PlayStation 3 games on the market.

But with Vulkan and Unreal now both available on mobile devices, Epic are promising high end game console features on mobile devices going forward.

“This scene has been rendered in real time using the Unreal Engine. It’s running live, and the operator, is right here in the audience,” said Epic Games Founder Tim Sweeney at the Samsung Galaxy Unpacked 2016 event in Barcelona.“Thanks to the new Vulkan API, we can render objects four times faster than in OpenGL, enabling high-end graphics with low power consumption.

“Now this is a simulation of celestial mechanics. Meteors are colliding and coalescing enhanced by particle systems, emissive materials, dynamic shaders, and other physically based rendering effects. Features that were once only possible on a high end game console now run on a device that fits in your pocket.”

This, of course, seems to line up with a report from earlier this month, which claimed that mobile game graphics would catch up to PS4 and Xbox One by next year- and as much as you and I would probably want to not take reports like these seriously, I would say that the creator of the biggest third party middleware engine on the market probably know what they are talking about.

Nintendo are an integral part of the gaming industry, but thy have always, for the most part, shunned standards, choosing instead to stick to proprietary solutions. This used to work well for them back in the day, but in the modern era, has made them increasingly isolated from the larger AAA gaming industry landscape and ecosystem.

However, Nintendo fans often pin the hopes of a triumphant comeback for the company on the mysterious upcoming Nintendo NX- we don’t exactly know what the NX is, but it does seem to be encouraging, from the bits and pieces about it that we have heard so far.

In September, we learned that Nintendo had joined the Khronos Group, which sounded encouraging at the time- after all, they are intimately involved with promoting Vulkan as an open source next generation API. However, there was no explicit association with Vulkan, not back then anyway.

That changed today- in the Vulkan Launch Webinar, a slide showed Nintendo as one of the groups that had participated in the creation of the Vulkan API (along with countless others). This immediately sounds encouraging- are Nintendo poised to use Vulkan on the Nintendo NX? That would bode good news for the console, its power, its adherence to standards, and the kinds of games that it may be able to run.

Let’s hope this is true.

Nintendo is expected to make some kind of preliminary announcement for the Nintendo NX in March.

"We’ve had a very good results with DX12. We’re pretty far along with our Vulcan support. We’re phasing out the Mantle and phasing in the Vulcan. We don’t have it working yet because the spec isn’t quite in provisional yet. It will be soon."

Ravi: Can you tell us a bit about yourselves and Oxide Games; and how you started it; and how you first got into games development?

Dev Team: That can be a long story. (Laughing) The founding members of Oxide. We’ve all been in the industry for a really long time now. Probably been in the games industry 20 plus years. We’ve all been developing software for a really long time. Did a bunch of different stuff. During the course of our careers we met each other along the way. At the end of it we all wound up at Firaxis.

Ravi: Yeah, Sid Meier’s studio.

Dev Team: Right. We wanted to try out some new, riskier things and that’s difficult to do in a publicly owned company. That’s why we decided to form Oxide Games and take some risks on what we thought would be disruptive game technology that we could tie in with multi-core, next-gen API.

Ravi: Nitrous is the key thing here because Ashes of the Singularity is on it. When you first announced it, it caused that “disruption” you’re talking about. It’s been some time since the announcement. What sort of changes have you made to the engine over the years?

Dev Team: Whenever you’re building new technology you start with a problem. And a theory on how to solve that problem. You put that solution into practice and see what problems that solution caused. etcetera, etcetera. That’s where we started. We had a lot of ideas on how we’d utilize multi-core. We had a lot of ideas on how we could tie that into both gameplay and graphics for next gen APIs. What we’ve been doing since then is a refinement. The biggest thing we’ve noticed is that everything matters. We found ourselves changing in terms of synchronization, and that can really destroy a multi-core engine. Our interest isn’t just frame rate, but fast to get into it. Last night I tested it. From launch to the executable when the main movie plays its 7 seconds on DirectX12 its 4 on DirectX 11. And that’s to load the entire content of the game. That was a theory we had about synchronize loading and how we form out the loading system to a variety of different cores. We refined that overtime. We do a lot of work with different performance tools. We try to study the frame. One thing we focus on is we don’t just assume there’s a problem we try to track it down and make sure it’s the problem before we try and solve it.

Ravi: When you first introduced Nitrous you were one of the biggest supporters of AMD’s mantle API. Has the tech been converted into a universal API which is the Vulcan API? Given that you are supporting Vulcan has this made the Nitrous Engine a platform agnostic engine of sorts, which gives better compatibility across several devices and consoles?

Dev Team: I would say that probably true. We’ve had a very good results with DX12. We’re pretty far along with our Vulcan support. We’re phasing out the Mantle and phasing in the Vulcan. We don’t have it working yet because the spec isn’t quite in provisional yet. It will be soon. We’ve been spending out time trying to get early access out. We believe by sometime next year we’ll be showing off Vulcan. All indications are indicating that our engine is well build around next generation technologies. When the new APIs come, everyone’s got these new technician costs. DX11 comes out and everyone has DX9. But we’ve already found all that tech transition. We’ve paid that cost. They’re all completely next generation on everything. Adopting Mantle early has given us an edge. We’ve already mapped out a lot of the models for next gen API. We have baselines; we know how fast things should be. When Mantle was new and being accepted, no one know what the results of that were going to be. Everyone had well informed ideas but no one actually sat down and proved how well it could work out. By adopting Mantle early, it’s made out transition to DirectX 12 a lot easier. We’re confident that those platforms are going to work out really well. For us.

"We built Nitrous. We didn’t just build an engine and say “we’re going to go out and compete with Unity and Unreal.” We built Nitrous because Unreal and Unity could not handle the type of games we wanted to make."

Ravi: One thing that’s defined Ashes of the Singularity is that it’s one of the first games that will utilize DirectX 12 — it’s been built for it. What kind of benefits has this resulted in when used in conjunction with the Nitrous Engine?

Dev Team: There are lots of benefits. The direct control is really big. We can guarantee smoothness and get rid of hitches and do synchronization. DX11 has a lot of bugs even after we send our game in. DX12 is so much cleaner. We all this performability early on in it. When we shipped DX11 5 years ago, with Civ 5, those drivers were a mess. The fact that DX12 is working this well so early bodes well for them. A lot of the problems we were just anticipating would just go away.

There are a few things we’ve been able to embrace: object space, lighting. If you look at the next gen API they are what really make those technologies feasible. Both of them require increased draw count. If you look at it in DirectX 11 it was a very batched limited API. Two of the fundamental technologies we developed and embraced both the temporal anti-aliasing and the object space lighting require a significant increase in the number of batches that can be submitted to the GPU. Without that we would be more limited. If you look at Nvidia’s DirectX 11 driver performance, they’ve gotten what I would consider stellar results out of that. DirectX 12 should result in more stable game releases.

Ravi: When you consider that Nitrous has gone to that point where it’s going onto multiple platforms, and it has that compatibility — right now it’s only announced for the PC platform and given that it is compatible with the PS4 and Xbox One are there any plans to bring it to consoles? Is there anything stopping you from current-gen consoles?

Dev Team: No. We’ve worked really well on current-gen consoles. It’s strictly just what games we’re working on and what our customers are wanting us to ship from right now. It’s well suited for consoles.

Ravi: The game is going into early access in October 22. Besides gameplay feedback what is your current aim, what kind of data are you looking for? Say, for optimizing it across multiple GPUs for DirectX12 benchmarks and such.

Dev Team: We did our tuned benchmark back in August and this one isn’t set up for bench marking. We’re looking more for compatibility, troubleshooting stuff. We haven’t done an enormous amount of tuning for the GPUs and probably isn’t as useful for benchmarking. We want to make sure we can run on a wide variety of — especially — lower-end hardware. We should be able to run and scale down on mobile parts and integrated graphics. From a technical stand point, make sure we edit the tech settings appropriately. We want a lot of feedback with the DX12 to make sure everything is working correctly.

Ravi: With regards to licensing the Nitrous engine. There’s been this thing in the past– this year actually: Unreal Engine 4 has gone free. Unity 5 also went free. How have these announcements affected your plans for licensing?

Dev Team: Two things about licensing. We built Nitrous. We didn’t just build an engine and say “we’re going to go out and compete with Unity and Unreal.” We built Nitrous because Unreal and Unity could not handle the type of games we wanted to make. We built Nitrous for the types of games Oxide wants to make. As for our plans for licensing, I don’t think we’re ready to announce that.

When we built Nitrous, our goal wasn’t to compete with Unity and Epic. The goal was we saw a serious of problems in the gaming space that we wanted to try and solve. Mainly that games were limited on their scope, their complexity. When you look at Unity and Epic those engines are really good content play back–especially sandbox games. Those engines aren’t very good at that. Nitrous is the opposite philosophy. It’s designed for more simulation, broad scope, and huge non-stop stuff going on.

We haven’t worried about competing in terms of price. If those guys want to fight it out to see who can be the most “free,” they’re more than welcome to do that. If you look at it, Unreal takes 5 percent on the back-end, and Unity takes a fair bit on the back-end.

People say it’s a fair bit, but it’s gross. It’s not that different from the previous model. They sort of changed which side they did that math on. They’re both fighting over certain developers. I think we’re in a different space entirely. They’re welcome to do what they want in the marketplace. It’s not much of an issue for us.

"When you try to get a game down into the 16 milliseconds consistently, it’s amazing how those milliseconds add up. Going to 30 frames per second is like gaining those extra milliseconds really is huge in terms of flexibility you’ve got there. It’s very difficult."

Ravi: In the past oxide games has claimed that DirectX 12 will improve visuals and this has become apparent on the PC. But DirectX 12 will also be coming to the Xbox One. As far as we know the Xbox One already has an API library which is similar to DirectX 12. Do you think this could be improved further when DirectX 12 actually arrives on the console?

Dev Team: We’re not experts on the Xbox One, but I can tell you what my understanding is. There are two benefits with DirectX 12 that are performance related. It’s a lot lower CPU overhead. That’s important because the CPUs on the consoles are not powerful. You have many of them but each one is not powerful. You’ll get a huge CPS benefit if you were having trouble with that by using DirectX 12. The other thing that DirectX 12 really does it offers more support for advanced GPU features. And there’s not a great way of doing that at all on DX11. By enabling that on Xbox One you can get pretty big (word sounds like per, or perf? Can’t understand) improvements on consoles. There should be tangible benefits. It will take people a few years to acclimatize to how to program and get those benefits.

Ravi: Like you said, it reduces CPU overhead. Can this, for Xbox One in the long run, can it result in games pushing out more pixels or a better resolution or better FPS?

Dev Team: Sure. If you use synchronous compute feature, if you optimize your research transition barriers that you have direct control over for DirectX, there are things you can do that you have no way to analog in DX11. There’s potential for substantial performance improvements which could manifest in increased resolution and frame rate.

There’s also additional benefit for developers to invest in trying to really pull the most that they can out. So they can bring that directly back to the PC. Because if you have to build two different paths you have to optimize one over the other. That’s as much a budget and a resource issue as anything else. It certainly is going to encourage people to invest more in that technology.

Ravi: Microsoft is working on– they’re trying to make Windows 10 a singular platform across every system, with Xbox One having that along with the PC having that as well. They’re encouraging a lot of cross platform compatibility between it. Do you think this kind of feedback that comes back and forth between developing on Xbox One and on PC, is it like a mutual benefit between the two platforms? This kind of work that’s being done.

Dev Team: Yeah. I think it is. It’s certainly very attractive for a developer to have to have a unified platform. To be able to code on DirectX 12 and be on the PC and then put it on the Xbox with minimal changes is hugely beneficial. It definitely homogenize their platform. Instead of Xbox One as a separate platform and Windows 10 as a separate platform, now you just have Microsoft as one platform and that’s clearly a lot simpler.

Ravi: One thing that’s been a major issues with the current gen consoles since they were announced– it’s been a PC issue since the beginning of time — from a developer’s perspective, 1080p at 60 frames per second: why do you think that isn’t a norm for this generation as such? Because when we looked back at the beginning there was all this hype that the new consoles would be capable of this and since then it’s like not many developers have been able to deliver on those promises, per se. Why do you think it’s been a struggle to balance between frame rate and resolution?

Dev Team: It’s simple math. Last generation consoles and this generation, I think the number I heard quoted was it was 6 times more powerful. That’s great, right? Then you do the math. You realize that if you’re running at 720p and going to 1080p you’ve doubled the number of pixels. If you were running 30 frames a second at 720 and you doubled your pixels and wanted to double your frame rate, you just used 4 more per and you have no more perf. Then you additionally want to increase the fidelity. You’ll see the same thing on 4k. It has 4 times the pixels as 1080. You need a GPU 4 times as powerful just to do the same thing you did before just at a higher resolution level with most engines. With Nitrous you actually don’t. That’s probably why you haven’t seen the big jump that some people were expecting.

It also takes increased bandwidth, etc. etc. When you try to get a game down into the 16 milliseconds consistently, it’s amazing how those milliseconds add up. Going to 30 frames per second is like gaining those extra milliseconds really is huge in terms of flexibility you’ve got there. It’s very difficult. Every game generation you want to do something a little more ambitious. And to pack additional graphics plus additional AI, plus additional gameplay and everything else into 16 milliseconds can be really, really challenging. Especially when trying to do that consistently. The last thing you want to do is stutter between 60 frames per second and 30. You don’t want to jump back and forth there a whole lot. There’s a lot of people that will argue the development cost and the discipline it takes to make a game run consistently at 16 milliseconds is just very difficult to achieve.

There are other things you can say too. As resolution increases the computational cost increases. I think we’re one of the only engines out there that have been reinvestigating how you render a frame. To some extent, as the resolution increases, not only is there a cost of more pixels but those pixels are being faded in a very simple manner. As we scale up in resolution how can we change our rendering so it’s less expensive? Because we’re doing the object space lighting we actually would scale better as the resolution increases. If you run our games at 4K, a lot of engines are 3 or 4 times slower we’re like less than half speed.

"To some extent whenever you’ve got something new like DirectX 12, you need people to pioneer the way. Once they prove that it works then you start to see a greater adoption. It’s an exponential growth. Somebody’s got to start somewhere."

Ravi: When it came to optimizing Nitrous for PS4 and Xbox One, both consoles have a similar architecture. They’re both AMD based per se. Did you see any major differences in how the memory works or the number or GPU or ROPs and such?

Dev Team: I don’t think we can talk about differences that we can see. It’s not clear what part of that is for NDA and what part isn’t.

Ravi: The overall differences between the two APIs on both consoles and which one is easier to work with.

Dev Team: I think the PS4 has a pretty nice API. The PS3 had this thing called the GCN. They did something similar for PS4. It’s a bit of a learning curve, but it’s pretty good.

Ravi: Given that you have a close relationship with Microsoft with DirectX 12 and such, what are your thoughts on the adoption rates on the API and the feedback that you’re getting back from developers that have used it so far?

Dev Team: We have a pretty good relationship with Microsoft. I actually worked on DirectX years ago, so I know those guys personally. We gave Microsoft out entire mantle station and said, “have at it.” We worked back and forth with them for a year. They helped us a lot with the initial implication. We’ve learned a lot. The difference between DX12 and the previous API is that the previous API was designed by Microsoft and they threw it over the fence and hoped it worked. This time around we actually had everything working and prototyped before the API was finalized. We’re pretty sure that everything works great. That’s a huge change in previous ones. Consumer adoption seems pretty positive. DX12 works with a vast majority of GPUs. We’re not at a point yet where we would drop our DX11 support. We wish we could. Wish we could because we can’t completely take advantage of all of DX12 until we kill our DX11 version. We’re pretty happy with the adoption.

To some extent whenever you’ve got something new like DirectX 12, you need people to pioneer the way. Once they prove that it works then you start to see a greater adoption. It’s an exponential growth. Somebody’s got to start somewhere. I’m really glad we’ve got such a good working relationship with Microsoft and Nvidia and AMD because trying to pioneer a new engine on top of a brand new graphics API and a brand new OS is definitely challenging for everyone involved.

Ravi: In our last interview with Brad, he was talking about how Sony was considering opting for Vulcan on thePS4. What kind of advantages do you think this opens up in general to regards to the Nitrous engine?

Dev Team: From our standpoint, writing a back-end for PS4 is a few months cost and then we’re done. I think it’s a better move for Sony because that means people can invest money in API and it will work everywhere. It will be a lot easier for them to put their code onto.

Ravi: As regarding the GPGPU on both consoles using the Nitrous engine, the PS4 has wider computer for that and get more utilization out of the ALU. What’s your philosophy is on the GRGPU on the Xbox One and PS4. What’s your take?

Dev Team: The PS4 has more synchronous compute queues which could allow you to develop more dependency with gameplay. You could preempt work. I know I could give you a better answer — but I can’t.

"We really want to get those most of what we can out of your systems. We’ve been working hard to do that. It’s one of those things where the hardware guys need developers to produce content that utilizes it."

Ravi: That’s perfectly fine. The PS4 GPU is a step above the Xbox One’s. As you were saying earlier, you don’t have too much trouble when you’re scaling down the Nitrous engine to these different platforms. When you consider the GPU differences, how do you approach this situation? Are you able to scale accordingly to the hardware? Do you go for that or do you try to stick to the lowest common denominator?

Dev Team: We have this problem way more on consoles because we’re PC focused. PS4 and Xbox One are relatively in the same ballpark in performance. There are some differences. With PC space we have to 10x scale not like 30-40 percent type of thing. Our engine is built for integrated graphics. We’re going up to a Furry or a Titan. We have all sorts of knobs we can turn up and down. A lot of them are subtle. You may not notice a GPU that’s a little bit slower. Like 20-30 percent. I don’t know if you’d notice if one is that slower. The average person probably wouldn’t see that too much. We can hide that pretty well.

It goes back into investing in different rendering technologies. The object space lighting stuff is very ALU efficient. Because of that we got a ride range of stuff there that we can do. It’s also resolution independent. If you’re computer ALU bound we can change how much of the scene is shaded at what rate. Where as, say you’re triangle bound we can change the TXAA settings to get different settings there. We have a lot of different knobs use to control that. Most traditional renderers are fixed. You’ve got ‘low,’ ‘medium,’ and ‘high.’ It’s very difficult for them to scale because resolution is going to cut into them. There are a lot of things that hamstring them. Where as we have a lot more freedom to embrace whatever the hardware strengths are.

Ravi: As you said, you’re a PC focused studio and one of the main concerns that’s been coming out the various bottlenecks that have been coming between components. One of the main things we’re wondering is that GPUs and APIs they’ve been progressing at a very fast rate compared to CPUs and memory speed. Are there concerns about bottlenecks in the future in regards to CPUs and memory speeds? And why do you think the industry is not quite working towards making those CPUs faster, where as they’re working more on the GPUs and progressive APIs?

Dev Team: The main problem is chicken and egg. We’ve been told that the hardware guys don’t see scaling. No one’s using all four cores. And a lot of that is the API. They can’t make a single core much faster. But they can add more cores. But they don’t want to add more cores because the games are easier. So we’re in this sort of nasty pattern.

It’s a great question. We’ve been looking at this a lot. We’d be labeled hardware enthusiasts as well as developers. We really want to get those most of what we can out of your systems. We’ve been working hard to do that. It’s one of those things where the hardware guys need developers to produce content that utilizes it. It’s worse than the chicken and the egg because there’s also got to be some business case for it as well. It becomes more complex than a simple chicken and egg things. Aside from the core issue that we’re looking at I think bandwidth is the next interesting thing that we’re looking at. There’s bandwidth and latency. From what we’ve found, as you scale up both in terms of complexity of the game that you’re making such as an RTS, we’re not looking for thousands of units but tens of thousands of units.

The memory you need for that all of a sudden becomes an issue. If you want to look at it, all of a sudden you have 16 cores instead of 8 and trying to use the same memory bus. Again you’ve got a bottle neck problem. One of the interesting things here is we build our own systems and we generally check them pretty well. I’ve got an I7 development box and we had another I7 development box and one of them was running at 50 frames per second was our CPU score. The other was at 74. We were looking at them and knew there shouldn’t be that fundamental difference between the two. That’s absolutely impossible. There’s something clearly wrong here. I ended up running Vtune on the box that was running slower and we notice that the bandwidth on the slower machine was capped at 11 gigabytes a second. It turns out; whoever had built the box had put the two memory dibs in the single channel slots so it wouldn’t register. It registered a single channel to a dual channel memory. Once we fixed that it went right back up to 70 frames per second. We’re seeing cases where increased bandwidth is going to result in increased CPU performance. We’re interested in testing out the newer DDR4 platforms especially with the higher frequency RAM, lower latency.

Ravi: One thing I found interesting that the PCs that are having these problems come up every few years. The same issue we come back to it. Whereas with consoles which have that limited hardware for years and years at a time, they’re finding ways to think outside the box. With Cloudgen on Xbox One developing Crackdown 3 and such. What’s your overall take on the cloud that makes a static console more powerful? Is there something in store like that for Nitrous? Have you ever considered inserting cloud computing with Nitrous?

Dev Team: Like cloud rendering?

"I think the cloud tends to be much more successful when you’re aggregating data and crunching numbers and then spitting those results out to a large number of users. From either a shading stand point there’s a reduced bandwidth cost there and there’s latency tolerance."

Ravi: Yeah.

Dev Team: Maybe. There are things we could do. You could do significant rendering calculations on the host and upload them. The way our engines works there are no latency issues. You might see some occasional rendering every now and again. So we haven’t really invested in it. Other than to know the architecture is compatible. From a business standpoint we’re always skeptical when we see cloud computer. The reason why is when you add up all the overhead in a big machine somewhere else, it’s not that expensive to have a machine locally. It’s never clear when it becomes a benefit.

I think a lot of it tends to wind up, as Dan says, a cost calculation. I think the cloud tends to be much more successful when you’re aggregating data and crunching numbers and then spitting those results out to a large number of users. From either a shading stand point there’s a reduced bandwidth cost there and there’s latency tolerance. If you look at AI generation and running AI in the cloud that becomes a really interesting idea. Because you can aggregate a lot of different users results, put them together and then dynamically form that data back out to other players. If you’re doing procedural generation of various parts of worlds or things, you’re streaming some of the results down, I think there are a lot of ways that that can work. But you definitely have to be careful about it.

Ravi: Coming to Ashes of the Singularity, the first thing I was wondering with regards to the gameplay: when I saw the concept for the gameplay there was tens of thousands of units on screen at the same time; and there were these battles happening simultaneously; what really struck me was that this is very similar to Total Annihilation.

Dev Team: I would say Total Annihilation is a good comparison.

Ravi: Even Planetary Annihilation.

Dev Team: I would say that Total Annihilation and Supreme Commander. There’s really like 4 different touchtone groups: there’s Total Annihilation, Supreme Commander, Company of Heroes, and Starcraft. I think all 4 of those games have provided, hopefully, an informed decision. Whenever we’re forced with a decision to make in the game those are the games we go back to the most and take a look at.

Ravi: When you look at the gameplay model itself there’s always that concern Supreme Commander was coming out there’s that concern that, “how are people going to manage when battles happen all at once.” How are you going to cater to the hardcore strategy gamers, but also help newer gamers to get into it as well? How will you manage these concerns?

Dev Team: We use traditional tools: there’s mini maps and there’s an expanded map to help give you an idea of what’s going on. In addition we have something we call the “Empire Tree.” Basically, it’s very similar to what’s in Sins of a Solar Empire. Keeping track of what units and factories are doing. And as much automation as we can get away with.

We’ve got the battle groups. Battle groups can have a hundred guys in it. And you’re managing them with one order. The production queue has been modified.

You can order reinforcements from units. If an army at the front gates needs more guys they can just say, “some factory, please send me these guys as soon as possible.” Things like that help speed up and help manage gameplay. Anywhere that we’ve noticed that it tends to be tedious or extra work to go back and do something we’re trying to remove those bottlenecks where we can.

"I think we’re actually more set up for the next generation, whenever that’s going to be. Not that we know anything of what it’s going to be or anything yet. If you double the cores and increase the GPU Nitrous will scale."

Ravi: With regards to what you’re going to have with Early Access– there’s going to be a skirmish mode, 1v1 multiplayer, and 3 medium sized maps for both single and multiplayer. What are the long term plans for the game in terms of content? What kind of maps, modes are you going to add into it?

Dev Team: Oh my goodness. That’s a huge question. I would say the best thing to do would to follow up with Brad on that and see what he’s got planned. To some extent, to be very frank and honest some of that is going to be based on the user feedback for Early Access. Some of that’s going to be based on feedback when we launch the game. There’s stuff users are really excited about and we’re going to focus on that stuff rather than focus on stuff we think is going to be more interesting. We want to make sure the users are enjoying themselves and having a good time. Some of the things we’re interested in is making sure people can access to as many maps as they can. There’s a couple ways we’re looking at that. We’re also looking at different terrain types. The game modes is also very interesting. I think we’ll likely be — not in Early Access — for release and beyond we’ll be looking at adding different types of game modes, not just traditional skirmish.

Ravi: The final question I have and I’m not sure how you’re going to answer this. There are these rumours going around with Nintendo’s next platform, which is the NX. How are you going to get a PC to run a high end– we need a high end CPU and GPU chip just to run the tech demo. I was wondering your thoughts on that. Given that we’ve already had one current generation of consoles and then we have this platform that’s apparently going to be even more powerful. What are your thoughts on that and how Nitrous Engine will scale as the next wave of consoles approaches?

Dev Team: I don’t know anything about the NX. You probably know more.

Ravi: I probably don’t.

Dev Team: I don’t know what they’re building. I think we’ll run great on it. I think we’re actually more set up for the next generation, whenever that’s going to be. Not that we know anything of what it’s going to be or anything yet. If you double the cores and increase the GPU Nitrous will scale. We’ve done 16 threads. We’ll scale with 16 cores right now. The only reason I’ve tested higher than that is because we don’t have more in the machine than that. We’re well prepared for the next gen tech transition. If someone’s going to ship a console with double the performance of the current consoles, we’d definitely love to play around with it. I think we’d be very successful there.

The new generation of graphical APIs is here- both, DirectX 12 and Vulkan look incredible, and look like they will be able to extract far better and more impressive performance from games than anything before. At this year’s Game Developer’s Conference, AMD is promising that it will share its insights on these two new APIs with developers, presumably demystifying them in the process.

“Vulkan and DirectX 12 are new, low-level APIs which require developers to think about graphics in a new way,” AMD says. “In many cases game engines need to be restructured to take advantage of low-level parallel submission, asynchronous execution and new state & resource handling features provided by the API. In this lecture, these new concepts will be reviewed and we will take a look at how launch titles successfully handled the transition to the new APIs. The presentation will include useful insights gained while developing the first wave of Vulkan & DirectX 12 titles.”

Hopefully, this kind of a presentation will spur more adoption of these APIs by third party developers- so far, in spite of all the hype surrounding them, not many DirectX 12 or Vulkan games really exist.

At the recently completed Siggraph event, Valve’s Dan Ginsburg talked, among other things about the new and upcoming APIs involving DirectX and Vulkan. Ginsburg said these APIs are set to offer low-level access to the GPU and CPU, thus improving performance in games. Ginsburg has been working very closely on Vulkan for Valve and talks about the fact that he doesn’t see any reason for game developers to create a DX12 back end for their games. He added that in general he feels as though Vulkan is far superior technology.

“Unless you are aggressive enough to be shipping a DX12 game this year, I would argue that there is really not much reason to ever create a DX12 back end for your game. And the reason for that is that Vulkan will cover you on Windows 10 on the same class of hardware and so much more from all these other platforms and IHVs that we’ve heard from. Metal is single platform, single vendor, and Vulkan… we are gonna have support for not only Windows 10 but Windows 7, Windows 8 and Linux.” Ginsburg said at the event.

It should be pointed out that Ginsburg might not stand alone in this opinion, but he’s certainly still in the minority. More and more developers are looking to support DX 12 than ever before. He’s also got an inherent bias since he’s worked so closely with Vulkan over the past few months. Whether you agree with Dan or not, you can watch his entire talk about these APIs in the video below. it is a rather long video but Ginsburg gets to the heart of the matter at the 1:40 minute mark.