Yeah, very cool! It was that very idea of clustered feedback applied to a simple equation, that was being observed creating wonderful patterns in the petri dish, that fractal coding was born of. Then it was like, doh!, these pattern forming interactions are happening all around in the physical world. It's the norm rather than the exception.
I remember news tibbits that went along the lines of we'll soon be able to encode all information as fractals ... Which might have been a tad too enthusiastic ... In hindsight, that was around the time when lots of new compression algorithms were appearing, including JPEG as the first(?) lossy compressor.
Pedward, I've not counted how long one iteration of fire takes.
There's a bunch of loops because there's a lot of pixels to scan, and you need two loops because you don't write to left and right edge of screen because you'd have to have checks for left edge and right edge you could do specific cases at start and end of inner loop but that just adds to time, so I leave it out.
So the inner loop is the X and outer loop is the Y.
Chip, I'm honored to have been able to teach you something you didn't know and yes I too like the natural look that comes from such a simplistic little chunk of code.
I guess that's why I also like the wireworld computer, because of the seemingly complex nature of the output from the simple formula of pixel generation.
Here is a variation of Baggers fire demo that works on the DE0 board with only one cog.
It uses 2 tasks. One task generates the video output with 256x100 pixels, the other task calculates the fire.
I have modified the fire algorythm a bit, so it will look different from Baggers version.
This version is for PAL video. If necessary I can also do an NTSC version.
You will need the binary palette file from Baggers ZIP in the first post.
Andy
Edit: Added a second version which runs much smoother (had again forgotten the POLVIDs)
Here is a variation of Baggers fire demo that works on the DE0 board with only one cog.
It uses 2 tasks. One task generates the video output with 256x100 pixels, the other task calculates the fire.
I have modified the fire algorythm a bit, so it will look different from Baggers version.
This version is for PAL video. If necessary I can also do an NTSC version.
You will need the binary palette file from Baggers ZIP in the first post.
PS, PAL looks great too! do you mind if I use it in my stuff?
For sure I don't mind. It took about 2 weeks to find out the right methode for PAL switching.
You should also look at the video line loop, it uses the CLUT8 video mode which I think is more efficient than the render subroutine with stackram.
I have added a second version to my previous post, that makes use of the POLVID instructions. The fire flares now much faster.
For sure I don't mind. It took about 2 weeks to find out the right methode for PAL switching.
You should also look at the video line loop, it uses the CLUT8 video mode which I think is more efficient than the render subroutine with stackram.
I have added a second version to my previous post, that makes use of the POLVID instructions. The fire flares now much faster.
Andy
Thanks Andy, and much better with the POLVID wonder how many times that will get us it'll be crucial when we get the real chip, other wise, all those cycles will be lost.
We could do a TV/VGA, keyboard, mouse, and serial driver in one cog I recon easy!
@Chip, I forgot to say about why it lifts to the left.
It's because I do vertical strips from the left, so when you've done the left strip, the next strip reads the flame in the left, and puts it higher in the right, but then the next frame, you get the right edge giving a reading when it reads the three, so sets the value, then when you process the next pixel down, because you set it on the right it raises left, plus from the bottom line where it was fuller, and so creates left drift. ( not sure I worded that correctly, if you need me to try to explain it better, let me know ) and I'll try graphically
It's mainly because you're not using double buffer, so you're basically getting feedback in the data.
It's because I do vertical strips from the left, so when you've done the left strip, the next strip reads the flame in the left, and puts it higher in the right, but then the next frame, you get the right edge giving a reading when it reads the three, so sets the value, then when you process the next pixel down, because you set it on the right it raises left, plus from the bottom line where it was fuller, and so creates left drift.
If I squint very hard at that, in the right light, for long enough I think I can start to make out the shadow of an idea. Of course I can never be sure if it's the same idea as the one that caused it to be written:)
The first time I ever put up Conway's Life years ago I forgot about the double buffering and it of course did not do what was expected. In this case the lack of double buffering seems to be to advantage.
I played with speech synthesis for a long time and finally came to the realization that to simulate vowels, albeit in a crude way, you could just run sine oscillators at the center frequencies of the vowels' formants, and then reset their phases on the pitch period. For example, to make an "eeeee" sound, mix sines of 300Hz, 3000Hz, and 3300Hz and then every 10ms (@100Hz), reset their phases to 0, so they start over again. You can think of this as having three bells that you strike in unison at 100Hz. Like magic, you get an "eeeeeee" vowel.
Later, I figured out that you can build resonators in software by simply maintaining coordinates (X,Y) that you rotate (QROTATE) at the formant frequencies, then chain them together in series by adding each resonator's Y into the next's Y. By feeding in a pitch or noise waveform, you've got a nice vocal tract whose output is a continuous function.
I suppose that if the flames listing to the right or left is a worry then one could do the updates in alternate directions each time to even things out.
Now I know how to make "fire". It's really interesting to find how simply natural phenomena can sometimes be simulated from almost nothing.
Here's another one - I wrote both fire and water demos on 386-level PC's years ago, and did a real-time, full screen julia set (real time = 30+ hz) on a 486. If the P2 can do fire, it can do water as well.
The applet above distorts an image using the resulting cell gradients, but it's also possible to just convert them directly to a color in a palette so you can see the ripples better. A palette going from dark blue to light blue to white looks really good.
Here's another one - I wrote both fire and water demos on 386-level PC's years ago, and did a real-time, full screen julia set (real time = 30+ hz) on a 486. If the P2 can do fire, it can do water as well.
The applet above distorts an image using the resulting cell gradients, but it's also possible to just convert them directly to a color in a palette so you can see the ripples better. A palette going from dark blue to light blue to white looks really good.
Jason
First fire, and now water! That is a very neat effect.
I looked over your Java code, but didn't glean the theory behind it. Could you please explain how the water effect works?
It's basically spatial diffusion effect, using the current height and previous height to compute the future height of the cell at a given position, plus damping.
If you've never seen it, you should take a look at my Reactor program, too. It might be a little hefty to implement on the P2 (it uses 2 floats per cell) but it might be possible to do it in fixed point. http://jasondorie.com/page_cnc.html
It's basically spatial diffusion effect, using the current height and previous height to compute the future height of the cell at a given position, plus damping.
If you've never seen it, you should take a look at my Reactor program, too. It might be a little hefty to implement on the P2 (it uses 2 floats per cell) but it might be possible to do it in fixed point. http://jasondorie.com/page_cnc.html
Jason
Your Reactor program won't restore from a minimized state, why is that?
Comments
I remember news tibbits that went along the lines of we'll soon be able to encode all information as fractals ... Which might have been a tad too enthusiastic ... In hindsight, that was around the time when lots of new compression algorithms were appearing, including JPEG as the first(?) lossy compressor.
There's a bunch of loops because there's a lot of pixels to scan, and you need two loops because you don't write to left and right edge of screen because you'd have to have checks for left edge and right edge you could do specific cases at start and end of inner loop but that just adds to time, so I leave it out.
So the inner loop is the X and outer loop is the Y.
Chip, I'm honored to have been able to teach you something you didn't know
I guess that's why I also like the wireworld computer, because of the seemingly complex nature of the output from the simple formula of pixel generation.
Evanh, thanks, and very true
It uses 2 tasks. One task generates the video output with 256x100 pixels, the other task calculates the fire.
I have modified the fire algorythm a bit, so it will look different from Baggers version.
This version is for PAL video. If necessary I can also do an NTSC version.
You will need the binary palette file from Baggers ZIP in the first post.
Andy
Edit: Added a second version which runs much smoother (had again forgotten the POLVIDs)
NICE work.
Function correctly on my PAL LCD TV !!!
PS, PAL looks great too! do you mind if I use it in my stuff?
For sure I don't mind. It took about 2 weeks to find out the right methode for PAL switching.
You should also look at the video line loop, it uses the CLUT8 video mode which I think is more efficient than the render subroutine with stackram.
I have added a second version to my previous post, that makes use of the POLVID instructions. The fire flares now much faster.
Andy
Thanks Andy, and much better with the POLVID
We could do a TV/VGA, keyboard, mouse, and serial driver in one cog I recon easy!
I think I'll have a look at CLUT8 also
Cheers,
Jim,
It's because I do vertical strips from the left, so when you've done the left strip, the next strip reads the flame in the left, and puts it higher in the right, but then the next frame, you get the right edge giving a reading when it reads the three, so sets the value, then when you process the next pixel down, because you set it on the right it raises left, plus from the bottom line where it was fuller, and so creates left drift. ( not sure I worded that correctly, if you need me to try to explain it better, let me know ) and I'll try graphically
It's mainly because you're not using double buffer, so you're basically getting feedback in the data.
The first time I ever put up Conway's Life years ago I forgot about the double buffering and it of course did not do what was expected. In this case the lack of double buffering seems to be to advantage.
I know, I kinda thought that after writing it, haha, oh well, at least you knew, kinda!
And yes, the lack of double buffer is a win in this case!
I played with speech synthesis for a long time and finally came to the realization that to simulate vowels, albeit in a crude way, you could just run sine oscillators at the center frequencies of the vowels' formants, and then reset their phases on the pitch period. For example, to make an "eeeee" sound, mix sines of 300Hz, 3000Hz, and 3300Hz and then every 10ms (@100Hz), reset their phases to 0, so they start over again. You can think of this as having three bells that you strike in unison at 100Hz. Like magic, you get an "eeeeeee" vowel.
Later, I figured out that you can build resonators in software by simply maintaining coordinates (X,Y) that you rotate (QROTATE) at the formant frequencies, then chain them together in series by adding each resonator's Y into the next's Y. By feeding in a pitch or noise waveform, you've got a nice vocal tract whose output is a continuous function.
@heater, very true!
Here's another one - I wrote both fire and water demos on 386-level PC's years ago, and did a real-time, full screen julia set (real time = 30+ hz) on a 486. If the P2 can do fire, it can do water as well.
http://www.neilwallis.com/projects/java/water/index.php
The applet above distorts an image using the resulting cell gradients, but it's also possible to just convert them directly to a color in a palette so you can see the ripples better. A palette going from dark blue to light blue to white looks really good.
Jason
First fire, and now water! That is a very neat effect.
I looked over your Java code, but didn't glean the theory behind it. Could you please explain how the water effect works?
It's basically spatial diffusion effect, using the current height and previous height to compute the future height of the cell at a given position, plus damping.
If you've never seen it, you should take a look at my Reactor program, too. It might be a little hefty to implement on the P2 (it uses 2 floats per cell) but it might be possible to do it in fixed point. http://jasondorie.com/page_cnc.html
Jason
Your Reactor program won't restore from a minimized state, why is that?