> I see. So we have two chemicals, who's concentrations are governed by a 
> new, more complicated pair of differential equations. Is that basically 
> what it means?

I think the equations are actually *simpler* than the wave equation because 
it gives you the velocity of the concentrations directly (not the 
acceleration).  One less integration step to perform, and no need to keep an 
array of velocity information.

>> If I get time I would like to try and implement this in a pixel shader, 
>> it's exactly the thing that GPUs are good at - performing the same code 
>> on a huge number of different pixels.
>
> More precisely, doing the some thing on a huge number of different pixels 
> *independently*. ;-) All goes horribly wrong with lots of data 
> dependencies. Still, for this, only neighboring pixels matter, so it 
> should still move like lightning...

Doesn't matter, because you cannot read pixels from a texture you are 
rendering to currently.  So you need to have one texture that shows the 
previous state, and then your pixel shader will write the new state into a 
new texture, performing as many look-ups from the old texture as you like. 
After you've created the new states then obviously you can swap the textures 
around for the next generation.

I'd then write another pixel shader that read form the two state textures 
and outputted to the screen back-buffer some colours, possibly using a 3rd 
texture as a look-up-table for speed.

> Took 2 hours at 320x240 on my Amiga 1200 with a 20 MHz FPU.

Oh I was down to about a minute or two at 640x480 on my 12 MHz Acorn (no 
FPU).  Limited zooming possibilities though.  Actually someone had written a 
much more complicated version in assembler that got around the accuracy 
limitations of 32-bit ints somehow and also ran faster than mine...

Post a reply to this message