Game of Life

[NoCforMe]

Heh; first of all, very nice you posted some files in my .GOL format. Kewl.
Yes, I've noticed that one pattern, the 5 cells that morph and move.
That "Gosper glider gun" is interesting: it oscillates between having two stable 2x2 squares, left and right, and absorbing and reforming those squares, all while emitting little gliders to the southeast (hence the "gun").

Very long-lasting too; I'm running this now and it's at 3800+ moves and still going strong. Seems to be non-terminating.

Hey, I found a Wiki on Conway/Game of Life, with this page on the Gosper stuff.

Thanks!

[zedd151]

Thanks tenkey.  Now I must start my version soon...

I have asked just now that this be moved to the Game Development board. I prolly shoulda put it there to begin with.    the thread was originally intended for discussing 'The Game of Life', not actually implementing it here.

[NoCforMe]

Boy, some people have waaaay too much time on their hands.

(There are 2 forms of the "queen bee shuttle", a "cis" version and a "trans" version!)

[NoCforMe]

Now I must start my version soon...

If I were you and I started a new version, I'd definitely think about at least one improvement to mine that sinsi suggested: Make the playing field wrap on all sides, so that things that reach the edges don't just die.

I leave this as an "exercise for the reader" to figure out.
@zedd: Some resources you might want to consult as you get into this project:

• This site,  "the wiki for Conway's Game of Life" is devoted to the game.
• The site "Catagolue".
• You might want to download Golly, a tool for creating Game of Life "objects".

[tenkey]

My glider gun search led me to the Simkin glider gun. I picked the pattern that shows the six bounding blocks (2x2 squares) and a subpattern that tells which way the central pattern is circulating (clockwise). There are four different orientations shooting in two different pairs of directions.

Add one glider eater and you have a "1-barrel" Simkin gun. The Gosper and Simkin guns are nonterminating.

You cannot view this attachment.

[zedd151]

Interesting stuff, NoCforMe and tenkey. 
More research material for me, or any other interested parties. 

[NoCforMe]

SimkinGliderGun.zip

Heh; looks like .gol is now the de facto standard.

Just kidding. It only works with my 60x60 playing field, for one thing.

[daydreamer]

SimkinGliderGun.zip

Heh; looks like .gol is now the de facto standard.

Just kidding. It only works with my 60x60 playing field, for one thing.

You could have v2 file format ,like BMP format header is stored width and height ?

[NoCforMe]

Well sure, adding width & height to the file header would be the next natural step.

I think I'll leave it to Zedd when he picks up the ball on this project ...

[zedd151]

Before I write even a single line of code, I have a few questions... 

Is each pixel plus its 8 neighbors evaluated from a 'snapshot' of all of the pixels state(s) from a given instant in time, and creating a new grid upon evaluating each pixel individually? (Derived from a single instant in time)

Or is each pixel evaluated and changed then moving on to evaluate the next pixel using the result of the previous changes done to the previous pixel without regard to the previous pixels original state? (Done sequentially)

I have not looked at NoCforMes code just yet, nor have I examined any other code for the game of life. Just pondering this on my back porch on my iPad. Depending on which of those is true, the outcome will be different. 

Not sure if I will ever get to this project though, as I have a half dozen other projects that I am wanting to finish first - and so little time lately for any real coding.

[FORTRANS]

Hi,

Is each pixel plus its 8 neighbors evaluated from a 'snapshot' of all of the pixels state(s) from a given instant in time, and creating a new grid upon evaluating each pixel individually? (Derived from a single instant in time)

   Yes.  You have the original displayed grid and you use it to
fill in a new buffer and then copy it to the display when all
is done.  Of course this is for "Conway's Game of Life", you can
always change how things happen and make "Zedd's Game",

Cheers,

Steve

[zedd151]

Thanks FORTRANS, that is what I had thought. But also thought that it was possible that NoCforMe was working with a single buffer and processing each pixel sequentially... 
I prefer to do it as intended in Conways original if possible.    no need to reinvent any wheels here.

I may have some free time to look through NoCforMe's code later today, and run his program in ollydbg and watch the data window for what happens while the game runs...

[daydreamer]

I was wondering if array of bytes for pixel evaluation,using only 0's and 1's
Like this
"101"
"010"
"110"
Mov eax,[ebx+array-1]; load 4 pixels
Add eax,[ebx+array-1-width] ; add 4 pixels above
Add eax,[ebx+array-1+width];add 4 pixels below
And eax,0ffffffh; reduce it to only add together 3*3 pixels
Add al,ah
Mov DL,al
Sar eax,16
Add al,DL
Switch al
Case ; here follows all cases that changes pixels

[tenkey]

Thanks FORTRANS, that is what I had thought. But also thought that it was possible that NoCforMe was working with a single buffer and processing each pixel sequentially... 

It's from a "snapshot". I don't expect gliders and glider guns will work properly if you "update in place". Updating in place is hard to do with pencil and paper.

I did the Gosper gun with pencil and graph paper long before I got a "home computer". (Consider that Life is ca. 1970 and the Altair computer was ca. 1975. The Big 3 of 1977 (USA) were Apple II, Commodore PET, and Radio Shack TRS-80.)

[NoCforMe]

Thanks FORTRANS, that is what I had thought. But also thought that it was possible that NoCforMe was working with a single buffer and processing each pixel sequentially... 
I prefer to do it as intended in Conways original if possible.

You really don't have a choice: it has to be done that way (evaluate all pixels, then make all the changes at once). It won't work any other way. (DAMHIKT)

What I do is make a list (an array of structures) of all changes needed as I look at pixels, then go through the list and make the changes (set cells to ON or OFF as needed).

I may have some free time to look through NoCforMe's code later today, and run his program in ollydbg and watch the data window for what happens while the game runs...

Spare yourself the trouble; it ain't that complicated. The whole thing is actually pretty straightforward. After all, it's a simple set of rules.

Look at my code in CheckCell(), which is where I evaluate each pixel by looking at its 8 neighbors and applying the rules. And GOLmove() shows how it all works together, checking each cell and then applying the changes to the game grid.