June 28th, 2008 at 12:52 am

Conway’s Game of Life

Jump to Comments
Submit to del.icio.us

Every time I try to learn a new programming language as a ‘Hello World’ world program I write Conway’s Game of Life.

So when John Resig created processing.js I started building again.

I’m not sure why, but the program is using a LOT of cpu cycles, I tried to optimize as much as I can, but i’m not sure if it worked as they were javascript optimization and I don’t know if they apply to processing too. Also I found out that some things still don’t work, most processing functions are working natively in javascript but some also don’t exist and are not put into processing.js yet. Like the function round, that like the name implies rounds the number to it’s closest integer value. I tried to submit a bug at the github page for processing but there is no such thing. The way I solved my problem is by simply adding 1 to the number and using the floor function that is implemented.

I’ve tried numerous ways of optimizing the program and been timing everything with the awesome add-on Firebug. The test results are noted in the code and if anyone knows any ways to optimize it better please let me know.

But let’s not ramble on too much about the code and just show it.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
/** A little test to see if processing.js is really that good...
                    -  So, not to break with tradition I wrote my usual Hello World
                    - Conway's Game of Life
                    -
                    - It has a couple of optimizations, namely calculating the new
                    - matrix and visualizing them is done at the same time.
                    - The matrix consists of a ring of 'death'cells as a safe sandbox
                    - to avoid memory errors
                    - The 2 matrices are not copied over after calculating, but they
                    - are swapped.
                    -   Loops are run in reverse because it's faster to check a value to
                    -   zero than to another value (w&h).

                    Author: Ezra Pool (ezra@tsdme.nl);
                    Version: 0.4
                */
      int a,b,w,h;
      int[][][] m;

      void setup() {
        h=250;w=250;a=0;b=1;
        m = new int[2][w+1][h+1];

        size(w, h);
        frameRate(5);

        spawn();

      }
      void draw() {

          background(255);
          lifedeathandshow();

      }
      void spawn(){
        int i,j;

        /**
                    -   Apparantly it's faster to run a loop in reverse because checking to see
                    -   if a value is zero is faster than checking another value (w & h).
                    -
                    -   Testing results:
                    -   normalloop: 148ms
                    -   reverseloop: 145ms
//*/
        for(i=1;i0;i--){
          for(j=h-1;j>0;j--){
            m[a][i][j] = floor(random(0,2));
          }
        }
      }

      void lifedeathandshow(){
        int c,i,j,n;

      /**
                    -   Apparantly it's faster to run a loop in reverse because checking to see
                    -   if a value is zero is faster than checking another value (w & h).
                    -
                    -   Testing results don't show much improvement, some rounds are faster
                    -   some are slower, but this is mostly due to the complexity of some of
                    -   the iterations. (More alive or dead cells).

        for(i=1;i< 2 || n > 3){
                m[b][i][j] = 0;
              }else{
                m[b][i][j] = m[a][i][j];
                point(i,j);
              }
            }else{
              if(n == 3){
                m[b][i][j] = 1;
                point(i,j);
              }else{
                m[b][i][j] = m[a][i][j];
              }
            }
          }
        }
        //*/

        for(i=w-1;i>0;i--){
          for(j=h-1;j>0;j--){
            n = neighbours(i,j);
            if(m[a][i][j] == 1){
              if(n < 2 || n > 3){
                m[b][i][j] = 0;
              }else{
                m[b][i][j] = m[a][i][j];
                point(i,j);
              }
            }else{
              if(n == 3){
                m[b][i][j] = 1;
                point(i,j);
              }else{
                m[b][i][j] = m[a][i][j];
              }
            }
          }
        }

        /** I don't know which of the two versions is faster in javascript/processing...
                          - is the temp variable one faster or the XOR swap??
                          -
                          -   Testing with Firebug in Mozilla/5.0 Gecko/2008062505 GranParadiso/3.0.1pre
                          -   Results
                          -   tempvar: 171ms (10.000 iterations)
                          -   xorswap: 203ms (10.000 iterations)
                      */

        c=b;
        b=a;
        a=c;

        //a ^= b;
        //b ^= a;
        //a ^= b;
      }
      int neighbours(int i, int j){
        return m[a][i-1][j-1] +
                m[a][i][j-1] +
                m[a][i+1][j-1] +
                m[a][i-1][j] +
                m[a][i][j] +
                m[a][i+1][j] +
                m[a][i-1][j+1] +
                m[a][i][j+1] +
                m[a][i+1][j+1];
      }
filed under processing

Leave a Reply