Measuring the Xbox One Against PCs With Titanfall 377
An anonymous reader writes "Earlier this week, Respawn Entertainment launched Titanfall, a futuristic first-person shooter with mechs that has been held up as the poster child for the Xbox One. The Digital Foundry blog took the opportunity to compare how the game plays on the Xbox One to its performance on a well-appointed PC. Naturally, the PC version outperforms, but the compromises are bigger than you'd expect for a newly-released console. For example, it runs at an odd resolution (1408x792), the frame rate 'clearly isn't anywhere near locked' to 60fps, and there's some unavoidable screen tear. Reviews for the game are generally positive — RPS says most of the individual systems in Titanfall are fun, but the forced multiplayer interaction is offputting. Giant Bomb puts it more succinctly: 'Titanfall is a very specific game built for a specific type of person.' Side note: the game has a 48GB install footprint on PCs, owing largely to 35GB of uncompressed audio."
Piracy prevention? (Score:5, Interesting)
The cynic in me wonders if the retarded idea of using uncompressed audio and not giving you the option to install just a subset such as the language of interest is some way of attempting to prevent piracy.
Maybe someone had the bright idea that people wouldn't bother trying to pirate that much data.
Maybe I'm just jaded.
Re:35 GB of uncompressed audio? (Score:5, Interesting)
It is as retarded as it sounds. There is absolutely no justification for it in this is this day and age. Using look ahead decompression and caching would be a net equal, or perhaps a smidgeon higher CPU usage. It means they are in effect wasting DMA bandwidth and CPU cache by streaming uncompressed files.
I'm a DSP guy by trade, and it's one thing that's obvious - game programmers don't know how to do sound properly.
They continue to insist on driving audio by the "main" game engine thread (see Valve's games with looping audio and stutters when things get busy). Or even when they dedicate a thread, they continue to use a push model for sound - when almost all modern audio APIs have agreed that a callback based model is the "correct" way. (The notable exception being OSS which is broken for this reason).
The pro-audio guys have pretty much nailed how you do low latency high priority audio, and the game programmers continue to get it wrong.
Re:1408x792 (Score:4, Interesting)
Per the article the Xbone is already choking and they are critical of the fact that they have the odd resolution with no real visible benefit while the game is unable to sustain 60fps.
The video is full of image tearing and stuttering.
Re:35 GB of uncompressed audio? (Score:5, Interesting)
My guess would be that they could not use the same compression codec used on XBox due to licensing issues, found that out only briefly before release date and didn't have time to redo it for the PC version and all they could get done in time was to pump the uncompressed audio files out.
My own view of Titanfall (Score:4, Interesting)
Titanfall is not a great game, but opinion aside - some odd facts. Has anyone noticed that the textures on the PC version almost seem excessively low res? I find this particularly baffling. The other thing that troubles me is that Vincent Zampella aparently tweeted on October 29th that he wasn't aware that Titanfall was going to be an Xbox One exclusive until just then (http://www.gameranx.com/updates/id/18380/article/titanfall-perpetually-a-microsoft-exclusive-respawn-unaware-ea-made-a-deal/). So, the only way he could have been unaware is that they were already working on a PS4 version and that the exclusivity deal announced in October quashed it. It just feels like a couple of these points kind of add up that Microsoft needed to make sure that it was exclusive and that the PC version wouldn't outshine the Xbox One version in the inevitable side-by-side comparisons. And, for its part, I must confess that I'm hard pressed to find much difference inthe Xbone-to-PC side-by-side videos.
In the end, I think the effort was wasted. There weren't many players broadcasting Titanfall on Twitch last night. And, as an avid gamer, it just feels like a lot of jockeying when versions of already-finished games are stopped with exclusivity contracts. I just can't get behind the Xbox One platform at all.
Re:35 GB of uncompressed audio? (Score:5, Interesting)
It is as retarded as it sounds. There is absolutely no justification for it in this is this day and age. Using look ahead decompression and caching would be a net equal, or perhaps a smidgeon higher CPU usage. It means they are in effect wasting DMA bandwidth and CPU cache by streaming uncompressed files.
I'm a DSP guy by trade, and it's one thing that's obvious - game programmers don't know how to do sound properly.
They continue to insist on driving audio by the "main" game engine thread (see Valve's games with looping audio and stutters when things get busy). Or even when they dedicate a thread, they continue to use a push model for sound - when almost all modern audio APIs have agreed that a callback based model is the "correct" way. (The notable exception being OSS which is broken for this reason).
The pro-audio guys have pretty much nailed how you do low latency high priority audio, and the game programmers continue to get it wrong.
As a professional game audio programmer, let me say that you're painting with a pretty large brush when you say that "game programmers don't know how to do sound." No offense intended, but you really shouldn't try to sound like an expert on game audio about unless you've worked on a AAA game engine. There are demands that games place on hardware systems that you really wouldn't understand. It's not like a DAW system where you can devote nearly 100% of the system resources to processing the audio. Yes, of course there are similarities, but the constraints and requirements are very different.
First of all, unless they're absolutely retarded, no audio programmer would push any sort of audio processing on the main thread. Sorry, but it just wouldn't, and isn't, happening. I don't even have to look at the source code to know that, because I know these guys aren't utter morons or incompetents.
Secondly, if you're a DSP guy, you're largely working at a level that game audio programmers do NOT typically work at - that is, the DSP and mixing level. Most game engines use professional third-party mixing/decoding engines with excellent, highly tuned code developed by specialists over many years of work, and are every bit as optimized as pro audio engines. Having used FMOD in our own game, I know it can decode and mix real-time compressed data in dozens of streams simultaneously, applying lowpass, highpass, reverb, echo, etc to them, and still only take up a small percentage of a single core. I believe Valve licenses the Miles Sound System, but I don't know for certain that this is the engine used in question.
That being said, I agree that leaving audio uncompressed seems unnecessary, at least for technical reasons. Having said that, I don't like to question the programmers judgment because I'm not there working on the project, and don't have all the fact. I have some recent experience with this, having recently shipped a game with a new, custom game engine I wrote that sits on top of the low-level FMOD mixing engine. We decided to keep all our samples compressed in memory, and were pretty impressed with the overall performance.
MP3 was used for most samples, as it has the most efficient decoder, and Vorbis was used when required for either seamless looping or multichannel audio. Additionally, each voice also had lowpass and highpass filtering performed on it. Dynamically calculated reverb settings and a custom echo filter I wrote was applied to the mix as well, plus the overhead of basic mixing operations, of which I used the highest quality 5-point spline-based mixing variation. We found that, on average, audio processing tended to take between 10 and 40 percent of a single core on a typical mid-grade PC (of about two years ago), depending on the level of activity going on at the time, with the vast majority of the CPU time used for audio decoding. Overall, it was pretty impressive to see all that being done in real-time without substantially impacting the rest of the game.
The real constraint in o
Re:35 GB of uncompressed audio? (Score:4, Interesting)
That's sadly a byproduct of how game engines are developed, I'm afraid. For the most part, game engines originate from graphics engine (so just graphics and then stuff tacked onto it), which means the vast majority of programmers working on the engine will be either generalist programmers or graphics programmers. In both cases, it's unlikely that they'll know how to deal with audio in any real capacity (I know I don't), so they'll use the same model that graphics uses: pushing commands.
Now, I'm sure that the larger devs have dedicated sound engineers, but I'm not sure just how much leeway they have with designing (and most likely, scrapping and completely redoing) the sound engine. It's also likely that their bosses will come from either a managerial background or a generalist programming or graphics programming background. Game development could use more specialists and needs to give them the flexibility they need.
Audio programming specialists like me are rare, but not unheard of. For most games, though, using a commercially available 3rd party engine is not only sufficient but probably preferred. So, the "audio programming" one is likely to do is mostly a case of resource management and integration with game development tools. It's the same reasoning as to how most games don't really require a custom-built game engine anymore - it's probably best left to the most specialized of games.
In my case, I was able to build a custom audio engine from scratch (yes, throwing away our old one) on top of the low-level audio API FMOD provides, but I think that's probably fairly rare nowadays, and for fairly good reasons. Our game was massive in scope, and had some pretty specific audio requirements and constraints, so it made sense to do this. I'd be pretty surprised if Titanfall had the sort of extreme requirements that we had, though, so they could probably get away with doing this. The fact that they could even fit all the uncompressed audio in a reasonable space demonstrates that there actually wasn't a lot of audio to begin with, at least not compared to the monster I was working on.
BTW, pushing commands works just fine for audio engines. In fact, it's the only sane way to do things at the high-level API, because that lets you efficiently and safely queue commands across a thread boundary. You're probably talking about push-vs-pull model audio processing, which is a complete non-issue, because game programmers almost never get down to that level of detail in the audio code. That's entirely handled by the low-level audio engine.