Just for fun! Finished in about an hour, although it's currently far too slow for my liking-- optimizations are more than welcome (especially for that augment()/seq() monstrosity in the middle of it).

Screenies:
Glider-- only loading 6 of the 16 total horizontal cells.

Loafer-- loading the entire field. Yes, it really is this slow.

[A] should be a 13x16 [that's 13 tall, 16 wide] matrix with its cells initialized according to the pattern you want; live cell is 1, a dead one is 0. The game doesn't modify the matrix, however (calculations are done by testing pixels), meaning that you can run the same pattern as many times as you want without changing [A].
If you want to start with a random field, replace 255[A](1+.1B,1+.1A) with 255real(8,3,2).

Code:
```real(0,1,1 real(7,9,0,0,160,120,0,1 real(7,9,0,0,160,120 For(A,0,60,10 For(B,0,110,10 real(7,3,A,B,255[A](1+.1B,1+.1A),10 End End real(9 While 1 For(A,0,60,10 For(B,0,110,10 real(8,1,not(real(8,0 real(7,1,A,B->E {2,3}=sum(0 or augment(augment(seq(real(7,1,A-10,B+X),X,~10,10,10),seq(real(7,1,A,B+X),X,~10,10,20)),seq(real(7,1,A+10,B+X),X,~10,10,10->L6 real(8,1,not(real(8,0 real(7,3,A,B,255(E and max(L6) or L6(2)),10 End End real(9 End ```
It looks like you are reading the state of each pixel from its color value on the screen. If you store the state of the screen in some sort of buffer, it will be much faster to access (because the parser will spend much less time), and you may even be able to vectorize some of the operations.

I wonder if a 44-pixel-high BASIC Game of Life could be done by storing 44 pixels in each element of a list of dimension equal to the width as bits in a binary integer.
That's precisely what I'm doing, but I'm not sure how buffering (I assume you mean using a matrix) would help much with speed; I'd still have to spend time iterating over the current cell's Moore neighborhood... and that's really the only thing slowing this down.
What do you mean by vectorizing operations?
Well, let's forget rounding errors for now and assume that a TI float can store 44 bits of information. We can store the screen in a list of say 100 elements, each one representing a column of pixels. Then the Moore neighborhood can be obtained quite easily. Say we want to know which of the cells to the left of column 42 are. That's just L1(41); the cells to the right are L1(43), the cells below are 2L1(42), and the cells above are .5L1(42). So we can add all of these up, and get a map of how many bits are set; then we can recalculate the pixels based on that.

The following code will work for base-10 storage, and is limited to 14 rows, but this can be expanded to 44 at the cost of speed.

Code:
``` Store the following list into L6: {10 10^2 10^3 ... 10^14} and its inverse into L5. //to display (by far the slowest part) For(Y,1,14 For(n,1,dim(L1) If int(10fPart(10^(-Y)L1(n) Then Pxl-On(Y,n) Else Pxl-Off(Y,n) End End End //to update 1.11(augment(L1,{0,0})+augment({0,0},L1)+augment({0},augment(L1,{0}))) seq(Ans(n),n,2,dim(L1)+1) seq(L6*(fPart(AnsL5)=.3 or fPart(AnsL5)=.2 and L1(n)),n,1,dim(L1->L1 ```

I think this should work.

Edit: Nope. At least seven errors. I'll fix it tomorrow.
Nice! This is long overdue!

Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

»
» All times are UTC - 5 Hours

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum