Calculator Community > Grammer

Conway's Game of Life

(1/3) > >>

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: ---<<begin loop>>
<<code>>
Pxl-Change(Y,X
DispGraph
Pxl-Change(Y,X
<<code>>
<<end loop>>

--- End code ---

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: ---.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

--- End code ---
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: ---:.0:
:0->A
:While A=/15
:getKey->A
:Un/D
:End
:Stop

--- End code ---

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

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?)

Navigation

[0] Message Index

[#] Next page