there is an example of conway's game of life in "processing: a programming handbook for visual designers and artists" that is confusing me.
at the end of the draw function, there are three lines of code:

int[][] temp = grid;
grid = futureGrid;
futureGrid = temp;

i just cannot understand why a temporary grid is needed and why you would want to save the old grid.  why doesn't this code work instead:

grid = futureGrid;

subpixel is right just like to add something about the game.

In Conway's "game of life" a cell maybe empty or contain a 'life'

At each step in time, the following transitions occur:
1. Any live cell with fewer than two live neighbours dies, as if caused by underpopulation.
2. Any live cell with more than three live neighbours dies, as if by overcrowding.
3. Any live cell with two or three live neighbours lives on to the next generation.
4. Any dead cell with exactly three live neighbours becomes a live cell.

If we had a single grid then changing a cell from life>death or death>life would adversely affect the calculation for its neighbour cells. We have to perform all the calculations for each cell without changing the starting values. Tie this in with subpixels's reply and hopefully you will realise why 2 grids.

You could probably do something like

grid = futureGrid.clone();

(Not sure if clone() does a deep copy of the array, but I'm sure there would be a method to do what you want).

Actively copying the contents of the array will almost certainly incur a performance hit.

-spxl

Quark wrote on Nov 1^st, 2009, 5:06am:

The other tricks are to not use 2D arrays, and to minimise the number of element accesses...

You don't need to count 8 neighbouring cells for each cell as you go along, because neighbouring cells have overlapping sets of neighbours.

I came up with a neat trick whereby you only need to look at 3 new cells for each cell calculation (instead of 9!)... well, except for the cells along the left edge of the grid (realisation: if you have many columns, the extra overhead for just the first column tends towards zero as an average for all columns, and hence all cells).

Conway_mod_by_spxl_1_3

Note: this program also does something a little different in that it doesn't calculate a futureGrid, as it were, but instead a "what are the changes grid"; I supposed that drawing the cells (plotting pixels) is slow, so instead of drawing the entire grid for each iteration, I only plot the births and deaths. This also allows for an interesting feature of plotting different colours to see a kind of history of the lives (and deaths) of the cells.

By the timing tests I'd run, this version runs nearly two and a half times as fast as the original that comes as a sample with the Processing environment, and represents the most advanced version of Life I've ever written. Having said that, it is still childs play compared to serious Life optimisations.

Check out a program called golly... you can run simulations thousands (or millions!) of cells wide and high at insane realtime speeds.