Conway's Game of Life

[awalden0808]

I've been playing around with cellular automata for a few days or so, and I really want to create the most famous one, Conway's Game of Life, in Grammer. I know the language pretty well, I just need to know if it would be possible to have two scripts running at once or something. I need to have a script that calculates the alive and dead cells, and a script to move a cursor around which will be used to draw. I can't have the pixel on the graph when I test for the cells because the program would treat it as a live cell. I was thinking of turning on the pixel, showing the graph buffer, turning off the pixel, doing the script to recalculate positions, then repeating, but I don't know if that will serve my speed needs, since I want to be able to move the cursor between generations. Any other good suggestions?

[Xeda112358]

Oh, wow, that would be really cool! I do not think Grammer will be able to do the whole screen quickly (I have made prime sieves using the whole screen and it could only get about .5FPS). However, a 32x32 portion of the screen or something sounds like it would be pretty quick! As for getting the cursor to run as well, that won't be difficult at all, fortunately

So, to display the cursor and not effect the screen:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8

<<begin loop>> <<code>> Pxl-Change(Y,X DispGraph Pxl-Change(Y,X <<code>> <<end loop>>

So pretty much your idea. That is indeed the fastest way, but you only need to use DispGraph once per cycle. Good luck!


EDIT: Also, for more ideas, you can store the graph screen to another buffer to compute each frame. For example:

(This is now a way to do CGOL, but it is slow )

Code: Select All | Copy To Clipboard

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

.0:Return Full 31→G           ;We are using a 32*32 region because 32 is a power of 2 pi9872→Z      ;use the actual pi symbol pi9340→W Repeat getKey(15 DispGraph Fill(8,Z          ;Copies the current graph screen to the buffer at 9872h For(A,0,G G and A-1→C G and A+1→D For(B,0,G G and B-1→E G and B+1→F Pxl-Test(C,E +Pxl-Test(C,B +Pxl-Test(C,F +Pxl-Test(A,E +Pxl-Test(A,F +Pxl-Test(D,E +Pxl-Test(D,B +Pxl-Test(D,F→H If <2 +H>3 Pxl-Off(A,B,Z If H=3 Pxl-On(A,B,Z End End Disp Z Fill(8,W Disp W End Stop

EDIT2: I have been periodically editing this between chores/classes. The current version gets only about .25 frame per second
Changing 31→G to 15→G for a 16x16 region can do 1 FPS
EDIT3: Because of this program, I have added a new command to compute 2^n (I used the token e^(). With it, I made a customisable version (so not just Conway's Game of Life). I also have wanted for a very long time to add a command to pixel test the border of a region, so this shall give me the excuse :3

[awalden0808]

Wow... That's pretty dang slow. I need at least 2 fps.

I knew how to use the Pxl-Change to leave the graph unaffected, but I wanted it to work out so that even if it did take a long time to calculate the new graph, you could still move the cursor during that time. It might be best to allow the graph to change, and then have the option to pause, and while paused you could edit the universe. Still, there's the problem of the program not detecting the button press while it's calculating...

TI-BASIC Dev had this solution for TI-BASIC. Probably not going to be of worth with Grammer, though...

[Xeda112358]

Yeah, it isn't exactly the best example of speed for Grammer, but I am trying to figure out what is being so slow. I can plot 1000 random pixels in about a second, but testing should be even faster. For 32*32, that is only 1024 pixels. I am going to check again because I was expecting to get maybe 6 FPS, originally, not a dismal .25 FPS.

EDIT: Okay, I took out the code making it wrap around and took off about 25 % of the time it took. I am testing with 64x64 which is much slower. It is now 11 seconds for one frame, so 32x32 should take less than 3 seconds. Not great, but I sped it up.

EDIT2: I added a new pixel test option to Grammer to test a rectangular border. This should be very helpful for collision detection in games and my gravity engine as well, but also manages 1 frame in 1.5 seconds.  I am still trying to get it faster. At 64x64, it takes about 6 seconds to generate a frame.

[awalden0808]

I feel I should remind you that YOU MADE THIS LANGUAGE. If you truly wanted to, you could add a token that updates the graph buffer based on the Game of Life rules. It would serve absolutely no purpose whatsoever other than for CGOL, but it would probably boost speed and free up hundreds of bytes of memory.

It also would take the fun out of programming it, but I really only wanted to be able to play Life on my calculator, instead of on my iPod Touch, where the environment is only about 18 x 30, and it wraps. Not a very useful size for making Glider Guns...

Say you used Un/D. The code would be:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8

:.0: :0->A :While A=/15 :getKey->A :Un/D :End :Stop

7 lines! GO!!! If you can implement particles, you can implement Conway's Game of Life!!

EDIT: I decided to find out what a prime sieve is, and then I made one with a really simple BASIC program that takes a number and divides it by every positive integer less than the number, and it then tests each quotient to see if it is whole (If C=round(C,0)). Not an algorithm necessarily.
Just curious: is that how you did it? Or did you use some fancy number thing? My program gave up at 337 due to memory overload or something (maybe because I wasn't clearing the screen?)

[Xeda112358]

Awesome! I was really really tempted to just add CGOL as a Fill( command, but I wanted the fun of coding it in Grammer. I felt like I would be ripping you off if I just added a command, but I really like the idea of UnD. Would you be okay with me really adding the command? I would make it just a general 2D cellular automata like my program used (which has a rule for CGOL).

Anyways, for the prime sieve, I made it in both Grammer and TI-BASIC using a similar idea. The main difference was that Grammer automatically splits up the remainder and whole value and uses a 64*96 screen. So in Grammer, I figured it had 96*64=6144 pixels to work with. So the highest prime you would need to factor out would be 73 (square root of 6144 is 78, the next lowest prime is 73). So the code:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Fill(0 For(A,2,73 If pxl-Test(0,A Then A+A→C 0→D For(B,C,6144 If C>95               ;for wrapping to the next line C-96→C:D+1→D B+A-1→B            ;we want to increment every multiple of A and For loops will add 1 automatically Pxl-Off(D,C C+A→C               ;get next increment End End DispGraph End Stop

This will result in black pixels representing primes (except for 0 and 1 which stay black, though they are neither prime nor composite). Of course, there is the command >Frac that can be used to test if a 16-bit number is prime or not, but that also takes out the fun of a sieve

[awalden0808]

Totally. I know that making it with Grammer is possible, and we both have done it (well, I need to get that buffer storing thing figured out first). So next step is speed. Yes, do it!

How are you going to include other cellular automata?

And wow. That prime sieve is a literal sieve. It take a big pile of numbers and takes out all of the primes. Mine takes one number at a time and sees whether or not it fits in the holes (of the sieve ).

So what good does it do to have the numbers on the graph? Will you then use a second program to figure out which number each corresponds to, then store them to a list? Or is there no purpose, just to say you did it? Or a test for a programming language?

EDIT: I don't know why but I've never been smart enough to just say "If pxl-Test(A,B" instead of "If pxl-Test(A,B)=1". Cool! New memory saving technique!

[Xeda112358]

Pretty much, my program works like this to get other forms:
There Surviving, Rebirthing, and Dying conditions based on the number of live pixels. Since there are at most 8 pixels, I can use 9 bits (for zero as well). If surviving is S, rebirth is R, and dying is Q:
S=4 (000000100b)
R=8 (000001000b)
Q is computed by using not(R or S

So if there are 3 pixels around, I do 2^3 to get 8 as a mask. "8 and R" returns nonzero, so I know it gets reborn. That, by the way, is CGOL
The main problem is that I haven't released the Grammer version with e^( which computes 2^n, but here is the code:

Code: Select All | Copy To Clipboard

1 2 3 4 5

If Q and e^(H        ;H is number of pixels around the cell Pxl-Off(A+1,B+1,Z If R and e^(H Pxl-On(A+1,B+1,Z

EDIT: Back from class, I didn't see your edit
So, for the sieve, you can pixel test a number to quickly figure out if it is prime It only works up to 6143, though

Also, for a few other memory saving techniques, you can try using If !pxl-Test(A,B instead of If 0=pxl-Test(A,B

[awalden0808]

Could you do me a favor and explain the graph buffer saving? I see that the pi symbol means hexadecimal, but what do the values correspond to?

[Xeda112358]

The values are actually RAM addresses. The calculator has 3 buffers the size of the graph screen (768 bytes).

pi9340 is the graph buffer that the OS uses

pi86EC is a 768 byte buffer that Grammer makes use of for temporary operations and whatnot. You are probably safe if you use this to very temporarily store a screen here or something. It gets used by text conversion routines and I believe that is all, now. I have been trying to make Grammer not use this buffer, so I will have to rewrite the text display routine. Pretty much, if you want to use this, you can probably start at pi87EC and be safe with 512 bytes of RAKM there

pi9872 is AppBackUpScreen. At the moment, Grammer initialises this with the first two bytes for the particle buffer. If you are not using the particle routines or you have set your own buffer, you can use this with no problems.


Also, I am about to test my first attempt at a 2D cellular automata as a Fill( option. I am sure it won't work this time, but if it does, I am hoping for 6 to 8 FPS in 6MHz (though it might be much slower ).

EDIT: Yeah, my anticipations went a bit too high it didn't work, but I am sure it only needs minor adjustments. It only gets about 2.3 FPS at 6MHz and about 6FPS at 15MHz

[awalden0808]

So cool how complicated it is to manipulate a 63x95 pixel screen.

I copied your code directly, but it still isn't working. I'm thinking some of my problems may be that I'm not using a recent file version. I have it downloaded to my computer now, so tomorrow I'll add it to my calc.

[Xeda112358]

You will want to use this version which is a prerelease, actually http://www.omnimaga.org/index.php?topic=10961.msg234112#msg234112 If you want, here is my current version of the program... It is a bit glitchy and I still have to tease out the specific bugs (it will draw in places where it definitely should not).

[awalden0808]

I just got the newest version from ticalc and yeah, I needed it. I stopped programming enthusiastically for a while (not sure why...) and I think my Grammer version was still from a few months ago. The UI looks better, and the file version is really nice to have there (actually something I was going to suggest, but since it's already there, no need to!)

And will adding the home run hook interfere with DCS7?
EDIT: To answer my own question: Yes, yes it will. I installed your hook, than the DCS7 hook. Ran a BASIC program, worked. Ran a Grammer program, didn't work. Installed your hook, ran a Grammer program, worked. Ran a BASIC program, didn't work. Maybe you and Kerm talk a bit and get a home-run hook alliance going?

EDIT: WHOA WHOA WHOA!!! When I installed your hook and added the .0: to the first line, the Program menu CHANGED!!! WHOA!!! WHOAAAA!!! Nice! Xeda, you have gone above and beyond the call of duty. As a token of my honor, I bestow this WHOAAA!!!! to you. "WHOAAA!!!!".

Except now I want to use the Send( command. How in the world do I do that? It's gone from the Catalog and Prgm menus.
Is that the "MakeVar" command? That makes sense.

[Hayleia]

EDIT: To answer my own question: Yes, yes it will. I installed your hook, than the DCS7 hook. Ran a BASIC program, worked. Ran a Grammer program, didn't work. Installed your hook, ran a Grammer program, worked. Ran a BASIC program, didn't work. Maybe you and Kerm talk a bit and get a home-run hook alliance going?

Same for zStart

[Xeda112358]

Yeah, I should get those to be compatible .___. I can definitely work on that, actually Also, I am glad you find the token hook appealing And yes, Send( is MakeVar(. If you need to check what the token names are in BASIC, you can change the header and it will automatically revert