Slashdot Mirror
Measuring the Xbox One Against PCs With Titanfall
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."
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.
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.
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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
Irony: Agile development has too much intertia to be abandoned now.