Each cog's LFSR updates every clock. The LFSRs are 32 bits, use a maximal-length tap set, and are reported with bits moved all around with some inverted. GETLFSR is there just for situations like this.
Nice one Chip, cheers for the rand generator
We always used to try making up new fancy effects back in the late 80s back on the speccy, and it just kept with us, through 16bit and onto PC etc.
The bottom two scanlines, are the seeding for the new flames, it's where I randomly set an amount of pixels to white.
Though now I'm waiting for the real deal. The thought of having windowed display areas by flipping DAC pins between COGs is very entertaining! I remember reading about CRTCA and CRTCB in the ET4000W32 information, however it seems like a feature that was never used by anyone. It allowed for windowed CRTC overlaid on the main CRTC output.
David, You don't need the latest config, as it uses cog-ram, and it's composite video on P0.
I assume the RCA jack labeled DAC0 is connected to P0. In that case, it isn't working for me. Should this work on an NTSC monitor or does it require PAL?
I assume the RCA jack labeled DAC0 is connected to P0. In that case, it isn't working for me. Should this work on an NTSC monitor or does it require PAL?
Okay, I guess this is my problem. I have the P2_Fire.spin code working now. I had been trying to load the .bin file using p2load and that didn't seem to work. I guess there must be some bug in p2load that I haven't encountered so far. The demo looks really nice!!
Okay, I guess this is my problem. I have the P2_Fire.spin code working now. I had been trying to load the .bin file using p2load and that didn't seem to work. I guess there must be some bug in p2load that I haven't encountered so far. The demo looks really nice!!
Duh... The binary file that was in the Fire zip file was a palette. No wonder it didn't work when loaded with p2load. I tried loading the P2_Fire.BIN created by PNut with p2load and it worked fine. Sorry for being so dense!
Sure beats a simple plasma! Looks great on the video! I'm stuck in O'Hare until morning due to bad weather. I almost took the DE2. Glad I didn't, because they don't know where my bag is!
Duh... The binary file that was in the Fire zip file was a palette. No wonder it didn't work when loaded with p2load. I tried loading the P2_Fire.BIN created by PNut with p2load and it worked fine. Sorry for being so dense!
So I now have one Question to them that upload that BIN files --- If them use (PA else other name) instead to differentiate that
I think I would have figured it out sooner except that downloading the palatte caused two of the LEDs to blink on my DE2-115 making me think that it was the real program that just wasn't working on my board. I guess I should try disassembling the palatte as code to figure out how that was happening.
Yes, Chip, pretty much what Roy said,
It basically gets 3 pixel values in a row from the line below the current pixel, and the middle pixel from the line lower again, divides the result by 4, if it's not black, ie 0, it reduces it by one, and the palette goes from 0-5f is black to red, 60-af is red to yellow, b0 to ff is yellow to white. to give the nice fiery colours.
there are many ways to collect the data, from surrounding pixels, and differing complexities on the maths behind deciding what the current pixel's colour should be.
But I find this method, pretty quick, and gives good results so kept with it, since the old days!
Yes, Chip, pretty much what Roy said,
It basically gets 3 pixel values in a row from the line below the current pixel, and the middle pixel from the line lower again, divides the result by 4, if it's not black, ie 0, it reduces it by one, and the palette goes from 0-5f is black to red, 60-af is red to yellow, b0 to ff is yellow to white. to give the nice fiery colours.
there are many ways to collect the data, from surrounding pixels, and differing complexities on the maths behind deciding what the current pixel's colour should be.
But I find this method, pretty quick, and gives good results so kept with it, since the old days!
Thanks for the explanation. That's pretty simple! How does it seem to blow to the left, though? And I guess this means that the bottom-most line of pixels must be randomly generated? Everything above the bottom-most line is deterministic?
Yeah, I liked the decent fire you get for the simplicity of the code. The bottom most line of pixels must be randomly generated, or at least patterned enough to look random, to keep the fire going ;D
And like you say, everything above the bottom-most line is deterministic
Yeah, I liked the decent fire you get for the simplicity of the code. The bottom most line of pixels must be randomly generated, or at least patterned enough to look random, to keep the fire going ;D
And like you say, everything above the bottom-most line is deterministic
Well, that is really neat!
Now I know how to make "fire". It's really interesting to find how simply natural phenomena can sometimes be simulated from almost nothing.
Comments
Yeah, the new maths features are an awesome addition to it's capabilities.
I just tried it - WOW!!!
Very nice work.
How did anyone figure out how to program fire? It looks really good.
The bottom two scan lines seems to be noisy, or is that some kind of data display?
What makes the bottom flames list to the left? If they go up straighter does it look less real?
...
Okay, I've played around with it a bit.
You can get rid of both instances of this:
ror seedas,#4
xor seedas,seedxo
add seedas,seedad
ror seedas,#1
xor seedas,seedxo
add seedas,seedad
ror seedas,#2
xor seedas,seedxo
ror seedas,#1
add seedas,seedad
...and just do this, instead...
getlfsr seedas
Each cog's LFSR updates every clock. The LFSRs are 32 bits, use a maximal-length tap set, and are reported with bits moved all around with some inverted. GETLFSR is there just for situations like this.
Is it possible to get a Youtube link for those with no DE2 to play with?
I was about to ask the same. It's very frustrating not being able to play along.
Sorry for the bad quality, my camera refuses to autofocus on the LCD screen. But it is better as nothing.
Whoa, thanks for that. What is going on there?
Nice one Chip, cheers for the rand generator
We always used to try making up new fancy effects back in the late 80s back on the speccy, and it just kept with us, through 16bit and onto PC etc.
The bottom two scanlines, are the seeding for the new flames, it's where I randomly set an amount of pixels to white.
Haha Coley Thanks!
Thanks for posting the vid nutson
Though now I'm waiting for the real deal. The thought of having windowed display areas by flipping DAC pins between COGs is very entertaining! I remember reading about CRTCA and CRTCB in the ET4000W32 information, however it seems like a feature that was never used by anyone. It allowed for windowed CRTC overlaid on the main CRTC output.
Thanks for the youtube nutson.
David, You don't need the latest config, as it uses cog-ram, and it's composite video on P0.
Yeah, you have to compile it, sorry, I should have stated that!
Glad it was worth the wait though
It was palete.
So I now have one Question to them that upload that BIN files --- If them use (PA else other name) instead to differentiate that
I'm just about to have tea, so once I've eaten I'll explain the theory behind it a bit
It's a form of Cellular Automata...
Here is a more advanced form with more complex math, but the basis is similar:
http://demonstrations.wolfram.com/SimulatingFlickeringFireWithNoisyCellularAutomaton/
It basically gets 3 pixel values in a row from the line below the current pixel, and the middle pixel from the line lower again, divides the result by 4, if it's not black, ie 0, it reduces it by one, and the palette goes from 0-5f is black to red, 60-af is red to yellow, b0 to ff is yellow to white. to give the nice fiery colours.
there are many ways to collect the data, from surrounding pixels, and differing complexities on the maths behind deciding what the current pixel's colour should be.
But I find this method, pretty quick, and gives good results
Thanks for the explanation. That's pretty simple! How does it seem to blow to the left, though? And I guess this means that the bottom-most line of pixels must be randomly generated? Everything above the bottom-most line is deterministic?
And like you say, everything above the bottom-most line is deterministic
Well, that is really neat!
Now I know how to make "fire". It's really interesting to find how simply natural phenomena can sometimes be simulated from almost nothing.