[PD] Spore [was: TR909 emulation]

[Andy Farnell]

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 at 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 at frey.co.nz
> frey | live art with machines | http://www.frey.co.nz


-- 
Use the source