Cellular automata in JPCT

I was looking for a diversion this week so i decided to attempt to recreate Conways Game of Life using shaders in JPCT for Android:

https://github.com/lawlessc/GameOfLife

I wanted to see if it could be done, and figure implementing to run in a shader in the GPU will be a lot faster than running it on a device CPU.

This is because Conways Game of Life could be called an "embarrassingly parallel" problem, as long as all cell calculations are completed by the next tick of course.

I reused code i wrote while attempting to create a fluid dynamics effect (failed project) as some of the methods to implement it, were similar, ie. passing the comutations back and forth between two textures.

The four basic rules of Conways Game of Life (taken from wikipedia) are:

1. Any live cell with fewer than two live neighbors dies, as if by underpopulation.
2. Any live cell with two or three live neighbors lives on to the next generation.
3. Any live cell with more than three live neighbors dies, as if by overpopulation.
4. Any dead cell with exactly three live neighbors becomes a live cell, as if by reproduction.

 I was able to implement this using the GLSL step function in two lines as show below.
I used step functions native to GLSL to avoid IF statements, as branching can slow down shaders.

float newval = ( step(neighbourcells.x,3.0) * step(  2.0 ,  neighbourcells.x)) * cell.x;newval += step(neighbourcells.x, 3.0)*step(  3.0 ,  neighbourcells.x); /

Below is a screen shot of this running on my android device. 

Because it's running at the device screen resolution you really have to zoom in to make out the cells.

I plan to keep going back to this to allow users to draw to the screen and make cosmetic changes etc.

A procedural world.

I decided before Christmas ,after learning just a bit more about shaders that i would attempt to make world at the centre of this game procedural instead of relying on textures.

The reasoning for this being :

• Reduce the number of textures stored in the app and in memory while it's running.
• Have a greater variety or worlds.
• Free myself partially from content creation(still an issue as i keep tweaking things)
• Build up a repertoire of techniques i can return to for later games, projects
• Expand my own learning of GLSL.

Some of the cons so far:

• What i sacrifice in memory usage is taken from GPU power and more device power usage
• The algorithms require a lot of tweaking to looking plausible and pleasing(this becomes a time sink, but at least i'm learning) 
• Testing all this slow.
• There maybe future unforeseen consequences, due to GPU changes that cause the code to behave incorrectly or simply not work at all.

To do this i initially started by working with a GLSL plasma function, i modified this (https://www.bidouille.org/prog/plasma )function to produce 3d noise instead of 2d based on the location of the point that is being drawn within the 3d space, as opposed to the points location on the texture. The reasoning for this is that it creates more seamless realistic textures on 3d objects such as a sphere.

1. By layering a few of these functions , having the results from some subtract and results from others add i created float representing height between 0.0 and 1.0. 
2. Using that i then set a cut off at 0.5,. Anything below is water anything above is land.
3. From there i can subdivide it further into, deep water, shallows, lowlands, mountains etc (citiy lights are just a texture so far)

Will updates this tomorrow with changes to this.