What you say is perfectly correct Damien and I cant fault the arument as far as you define predictability to be a human judgement. However I define predictability from a computer science POV which is different. In that sense a procedural implemetation is no more or less predictable than a data based approach.
The hidden (hard to see) advantage is that as you tend to the limit procedural audio combined with dynamic level of detail starts to beat the pants off data methods because you get a variable cost for dynamic sound objects while you are stuck with a linear, fixed cost per sample replay.
As far as important judgements in game development go the big picture is much more complex. Aesthetic judgements are just one axis of a multi dimensional tradeoff of runtime CPU efficiency, runtime memory footprint, runtime bus bandwidth, secondary storage requirements, development time, and aesthetic quality. Placing too much emphasis on just one aspect in order to allow one part of the team to exercise arbitrary on the fly planning is an unbalanced approach in my opinion.
On Wed, 11 Jun 2008 16:34:19 +0200 Damian Stewart damian@frey.co.nz wrote:
Andy Farnell wrote:
On Monday 09 June 2008 21:47:04 Andy Farnell wrote
I know from talks with EA guys that EAPd ran into some problems and its performance was not spotless. But not for the reasons you state.
Well, those reasons are the ones they gave me (or, if you prefer, what I understood from their answer) when I asked them at GDC.
Sure, fair enough. I'm saying that 'efficiency reasons' is succinct but incomplete. Like when politicians say 'security reasons'. It hides a whole nest of complex problems. They almost certainly misused the word 'predictable' when they meant to say 'limited'. Respectfully, Andy
hm.
i've worked with Pd on a CPU limited platform (PDA), and i've also worked in the games industry.
in the games industry, you can say to your sound department, 'you can have four channels of digital audio', and know exactly how many CPU cycles this is going to take. if you then go off and create sound is not to the Powers That Be's liking, it's an easy enough thing to drop in new samples, without effecting CPU usage.
with dynamically-generated audio, on the other hand, if the Powers That Be don't like the sound, changing it /will/ change the CPU usage, unless you can guarantee the same number of oscillators and DSP calculations - which would be unlikely for anything but trivial changes, or for changes late in the piece when the basic structure of the sound has already been laid out, where it's probably too late to ask for more CPU anyway.
so they're correct in saying that CPU usage for dynamic sound is not predictable, certainly not in the way that sample playback is. the trick, of course, is to get sound people who also know how to keep their CPU usage very low (consoles have absurdly small CPU power - the games they run look amazing because of very tight optimisations and clever coding), and the number of people with that level of skill is vanishingly small.
just my 2c.
d
damian stewart | +31 6 5902 5782 | damian@frey.co.nz frey | live art with machines | http://www.frey.co.nz