Cellular automata

[Kyle]

Meh it's pretty simple:

.love compatible with 0.8.0 and 0.9.0

It's a basic fluid pressure simulation, running it should explain everything. Let's see some other ideas!

[bekey]

-snip-

[Robin]

I made another one! Controls are displayed. For large factors, it takes a while to "start up". Very low factors are rather chaotic, if you're into that.

[jjmafiae]

And somehow dodge Atari's lawsuit

does Atari still exist?

[Kyle]

I made another one! Controls are displayed. For large factors, it takes a while to "start up". Very low factors are rather chaotic, if you're into that.

That is trippy, I love it.

[Robin]

Thanks! I made another one.

While I designed the previous one to have the "colours chasing each other" effect, this one I have no idea how it works (although the basics are pretty similar).

I've made some observations on it, though.

Colours tend to group, and change in colour is usually smooth. There are three base colours: yellow (FFFF00), cyan (00FFFF) and magenta (FF00FF). These are pretty resilient to a bit of chaos, but if they are to small, they shrink until they disappear. Then there are three supporting colours: red (FF0000), green (00FF00) and blue (0000FF). They form the boundaries between areas of different base colours. Between yellow and cyan sits green (FFFF00 & 00FFFF = 00FF00), etc.

There are small-scale self-supporting occurrences I still don't understand at all. I call them "knots". They are a small areas of about 2x2 pixels from which radiate all the colours. Knots can be either clock-wise or counter-clockwise. If a clock-wise knot and a counter-clockwise are close, they move towards each other and eventually annihilate each other, eliminating the base colour that was trapped between them, along with its two supporting colours. Knots can also annihilate against a wall. Knots that are both clock-wise or counter-clockwise do not move towards each other and if you "poke them" together, they will simply pass through each other. Knots are pretty resilient as well, aside from annihilation: randomising a single pixel of their centre does nothing, as does inverting a 3-by-3 area around the center (left mouse button and right mouse button respectively), at best moving them around a bit.

I didn't add a control for the factor in this one. You can change it in the source code if you want, but the only thing that seems to happen is that around a factor of 1.5, areas of pure black/white start to arise. The smaller ones shrink just like smaller areas of base colours. Black becomes white in the next update and vice versa. If the factor is higher than... I think 2 or so... those areas start to grow instead of shrink, leading to the screen be filled by large areas of black/white, separated by single pixel bands of changing colours. I think those flickering areas of black/white is annoying, so I set the factor low enough that they don't occur.