Dr. John Conways 'Game of Life'. (http://www.scholarpedia.org/article/Game_of_Life)
Would make an interesting project. I might in fact explore doing that, at some point in the future. :smiley:
Hi,
Yes, after it first appeared in Martin Gardner's "Mathematical
Games" column in "Scientific American", I tried coding up a
version of it. A long time ago, so memories have faded away,
but crude. And fun.
Steve N.
Quote from: FORTRANS on June 29, 2024, 08:30:14 PMI tried coding up a version of it.
A long time ago, so memories have faded away, but crude. And fun.
Steve N.
Hi Steve, seems a very doable project. I just have to get up the motivation to start working on it. Look for it in the Game Development board at some time in the yet undetermined future. :biggrin:
Quote from: FORTRANS on June 29, 2024, 08:30:14 PMHi,
Yes, after it first appeared in Martin Gardner's "Mathematical
Games" column in "Scientific American", I tried coding up a
version of it. A long time ago, so memories have faded away,
but crude. And fun.
Steve N.
Was it so long ago it was monochrome graphics with logic to shift bits (pixels) while add bits together ?
Modern version could use HD resolution graphics ,those old computers was limited to lowres graphics and slow CPU and tiny memory
Quote from: daydreamer on June 30, 2024, 01:52:37 AMthose old computers was limited to lowres graphics and slow CPU and tiny memory
But...
Was perfect for demonstrating 'The Game of Life' back in the day - plus the limitations made it much more fun to program I would imagine.
Don't really need high res graphics for such a simple program. And too much speed would result in not being able to see the 'action' without slowing it down enough. :smiley:
I will find out soon enough. Not sure yet how I will approach coding my example of it. Most likely will be 32 bit, though.
I will be looking forward to 32 bit version
Hi,
Quote from: daydreamer on June 30, 2024, 01:52:37 AMQuote from: FORTRANS on June 29, 2024, 08:30:14 PMHi,
Yes, after it first appeared in Martin Gardner's "Mathematical
Games" column in "Scientific American", I tried coding up a
version of it. A long time ago, so memories have faded away,
but crude. And fun.
Steve N.
Was it so long ago it was monochrome graphics with logic to shift bits (pixels) while add bits together ?
It was so long ago, that it was probably just pencil and paper.
Or maybe chips or coins on a checkerboard. So coding might be an
exaggeration.
Steve
Maybe someone else coded bit manipulation game of life code ?
I wrote something similar to very old code in dos 16 bit forum earlier : apple ii shapes made with bit encoded vectors
Hi,
If you look into the Forum Links -> Archive 2 -> 7908_STATE.zip
has a DOS program that is a video state machine, something like a
brain dead Game of Life. A search did not find the thread where
I originally posted it. {Rats.}
Steve N.
Hi,
The posting was in the old forum. It has some
information about the programs.
State Machine (https://masmforum.com/board/index.php/topic,14503.msg117412.html#msg117412)
Regards,
Steve N.
Thanks Steve, I'll have a look at that later today. :thumbsup:
So here's my first effort, a working demo. Shows a 60x60 "playing field".
Not the world's most elegant user interface, I'll admit:
To start a game, click "Restart". Then click in the field to turn cells "on". To start the game, click "Play". Make moves by clicking "Move".
Next I think I'll make it step automagically until it reaches a steady state (either all cells "dead" or no more changes happening). It should be easy to detect the latter condition, since I keep a list of all cells that have changed for each move. If it reaches a steady state, some cells will still be changing, but the number of changed cells either won't change, or will alternate between two values. (I think.)
Interesting game.
Oh, let me know if the thing is too big for you. It barely fits my screen (and isn't resizeable).
Size is okay. All cells die too quickly. Even for this small size, takes quite some time to fill in enough of them to let it live for any length of time.
Is there some way for you to fill in the starting positions with n number of cells turned on (user choice?), perhaps using a prng?
I havent even started any code for my version. :sad:
Otherwise your version seems is off to a good start.
New mo'betta' version attached, shows some stats.
How fast they die is entirely up to you. Sure, one could easily have some canned starting patterns. I'm not yet familiar enough with the process to come up with any. I have found that bigger, blockier starts tend to last longer. You'll have to experiment. (If you come up with some good patterns, let me know, maybe take a screenshot.)
Feel free to use anything from mine in yours, if it suits you.
Ok, I'll check this one out when I'm back in front of my computer. :biggrin:
So far so good. I didn't record the starting sequence, but for some sets of cells, they reach a point where they don't 'move' anymore. Example:
(https://i.postimg.cc/QMV3b6VY/untitled.png)
Only the 3 cell line changes between vertical and horizontal, the other patterns do not change any further. I'll have to investigate further as I find this interesting.
Only one quibble. When setting cells 'on', the user should be able to turn it off again, if it was a mistake or accident for example.
Maybe we could ask Stewart to move this to Game Development... up to you, as its your game being developed here. Maybe split it off from the post with your first code attachment?
Sure, whatever.
I'll add setting cells back to "off", easy enough to do.
And what you're seeing with those patterns that either oscillate (a line of 3 cells on that flips from horizonal to vertical) or just sit there (a 2x2 square) are classic behaviors of the "game".
Quote from: NoCforMe on July 04, 2024, 10:49:01 AMSure, whatever.
I'll add setting cells back to "off", easy enough to do.
okee.
QuoteAnd what you're seeing with those patterns that either oscillate (a line of 3 cells on that flips from horizonal to vertical) or just sit there (a 2x2 square) are classic behaviors of the "game".
I'll have to have a more 'in depth' look at the rulez. I only glossed over the rules before.
QuoteI'll have to have a more 'in depth' look at the rulez. I only glossed over the rules before.
The behavior isn't in the rules, it's just caused by them.
This is actually a quite complex little scheme, even though the rules are dead-simple.
The rulez:
- If a cell is ON and has fewer than 2 neighbors that are ON, it gets turned OFF
- If a cell is ON and has 2 or 3 neighbors that are ON, it stays ON
- If a cell is ON and has more than 3 neighbors, it gets turned OFF
- If a cell is OFF and has 3 neighbors that are ON, it gets turned ON
That's it. ("Neighbors" are adjacent or diagonal; each cell has 8 neighbors in a 3x3 array.)
Quote from: NoCforMe on July 04, 2024, 11:40:50 AMIf a cell is OFF and has 3 neighbors that are ON, it gets turned ON
Thats the part I was not seeing anywhere,
at least that I noticed. I only see 'death', no 'birth'...
I'll have more time later to play with this more. Maybe I was just missing that happening?... :smiley:
Nice work. Size is small on a 4K monitor, makes it fiddly to click cells.
I made one change to the code
;MOV [EAX + GameArray], 1 ;Set cell to ON.
xor [EAX + GameArray], 1 ;toggle it instead
QuoteMaybe we could ask Stewart to move this to Game Development
Agreed.
New version. Two added things:
- Autoplay: click the button and watch the game play itself.
- Save & load patterns: When setting starting patterns by clicking, you can save the pattern for later usage.
(Also fixed the grid drawing which had been wrong all this time ...)
Took me a while to figure out how to figure out when a game is over. The system I came up with seems reliable: if the # of ON cells goes to zero, obviously it's over. Checking whether the # of cells that change is the same as the previous move, AND the # of ON cells is the same proved not reliable, but it seems to work after I added a checksum (the sum of all ON cells plus their address in the array). There still may be some corner cases where this doesn't work, so if you see the game running on after it's obviously over, let me know.
Only thing I can see adding at this point would be some stats reporting at the end of a game.
Wish list
- adjust the delay for autoplay
- pause
- edge wrap
- size the window according to screen resolution (hard with multi-monitors though)
It's simple but fascinating :cool:
I get everything you listed except edge wrap: how exactly would that work?
Treat the left edge as an extension of the right edge and vice versa (& top & bottom)?
Resizing would be difficult but doable, necessary for a "real" game.
It could also stand a smarter paint handler instead of redrawing the whole damn thing every time.
Quote from: NoCforMe on July 05, 2024, 03:27:45 PMTreat the left edge as an extension of the right edge and vice versa (& top & bottom)?
Yep, like a flat sphere instead of a square.
So a Mobius square. Gotcha.
What happens if you start with random generated pattern ?
@NoCforMe: I had a chance last night to tinker with the latest version. Kudos, it works pretty much as expected. :thumbsup:
I am glad to see that I inspired you to write this program. :smiley:
Now if I can just get motivated to start my own rendition of it. :tongue:
Quote from: zedd151 on July 07, 2024, 12:52:41 AMNow if I can just get motivated to start my own rendition of it. :tongue:
Please do. I'm probably going to add just one more thing to my version (stats reporting) and that should be it.
Fairly simple "game", so pretty simple data structures.
After a while, you should look into gliders and glider guns. They were among the first interesting patterns to be discovered.
Gliders.zip
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 (https://conwaylife.com/wiki/Gosper_glider_gun).
Thanks!
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. :tongue: the thread was originally intended for discussing 'The Game of Life', not actually implementing it here. :biggrin:
Boy, some people have waaaay too much time on their hands (https://catagolue.hatsya.com/object/xp30_w33z8kqrqk8zzzw33/b3s23).
(There are 2 forms of the "queen bee shuttle", a "cis" version and a "trans" version!)
Quote from: zedd151 on July 07, 2024, 06:15:11 AMNow 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 (https://conwaylife.com/wiki/Main_Page), "the wiki for Conway's Game of Life" is devoted to the game.
- The site "Catagolue" (https://catagolue.hatsya.com/software).
- You might want to download Golly (https://sourceforge.net/projects/golly/files/golly/golly-4.0/), a tool for creating Game of Life "objects".
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.
SimkinGliderGun.zip
Interesting stuff, NoCforMe and tenkey. :thumbsup:
More research material for me, or any other interested parties. :biggrin:
Quote from: tenkey on July 09, 2024, 08:09:31 AMSimkinGliderGun.zip
Heh; looks like
.gol is now the
de facto standard.
Just kidding. It only works with my 60x60 playing field, for one thing.
Quote from: NoCforMe on July 10, 2024, 08:56:34 AMQuote from: tenkey on July 09, 2024, 08:09:31 AMSimkinGliderGun.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 ?
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 ...
Before I write even a single line of code, I have a few questions... :biggrin:
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. :smiley:
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.
Hi,
Quote from: zedd151 on July 10, 2024, 11:40:37 PMIs 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
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... :smiley:
I prefer to do it as intended in Conways original if possible. :biggrin: 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...
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
QuoteThanks 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... :smiley:
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.)
Quote from: zedd151 on July 11, 2024, 02:29:22 AMThanks 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... :smiley:
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).
QuoteI 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.
Quote from: tenkey on July 11, 2024, 04:36:15 AMQuoteThanks 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... :smiley:
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.)
Game of life in basic was published in computer magazine around 1980's ,when display was limited to 320*192 pixels and 8 bit CPU
Today on PC,you have much more freedom how to code it in 32 bit or 64 bit mode,many more instruction set to solve it with fpu ,sse2,avx,avx2
I don't know if pixelshaders can be used ?,but using point list in DX you get hardware acceleration
Wonder if zedd will try 64 bit version ?,mine might be code in SIMD just for fun
Quote from: daydreamer on July 12, 2024, 03:50:03 AMToday on PC,you have much more freedom how to code it in 32 bit or 64 bit mode,many more instruction set to solve it with fpu ,sse2,avx,avx2
I don't know if pixelshaders can be used ?,but using point list in DX you get hardware acceleration
Wonder if zedd will try 64 bit version ?,mine might be code in SIMD just for fun
Everything you listed is total overkill for this very simple "game".
Quote from: daydreamer on July 12, 2024, 03:50:03 AMToday on PC,you have much more freedom how to code it in 32 bit or 64 bit mode,many more instruction set to solve it with fpu ,sse2,avx,avx2
Really? How exactly would any of that be helpful here? What about 'backwards compatibility'? Would be more useful for any program to be backwards compatible for those that do not have the latest cpus in their computer, or the latest instructions. :smiley:
QuoteI don't know if pixelshaders can be used ?,but using point list in DX you get hardware acceleration
Why don't
you try it, and post an example? :biggrin:
QuoteWonder if zedd will try 64 bit version ?,mine might be code in SIMD just for fun
Never. I had already have had a
play with 64 bit coding, and will never do it again. I may look at 64 bit code from others though, from time to time, and even help with debugging it. But I'll never write any programs in 64 bit myself ever again. :eusa_naughty:
Quote from: zedd151 on July 12, 2024, 05:14:25 AMNever. I had already have had a play with 64 bit coding, and will never do it again. I may look at 64 bit code from others though, from time to time. But I'll never write any programs in 64 bit myself ever again.
Totally unnecessary for this application.
(I haven't yet written one (a 64-bit app) myself.)
well I usually stick to max SSE2 coding like others in this forum,because its minimum of W7 and can work with older computers and its my kind of fun code it SIMD
but right now I am concentrating on my card game ,getting console program right with game logic first before in campus,before GUI later
I have yet to write one single SSE or SIMD instruction in any of my code. And yet it works just fine.
I just pretend they don't exist.
Set your time machine for ~2004.
Although I'm getting old, I'm not afraid of 64-bit. So I've converted NoCforMe's code to 64-bit. The new code is more verbose than I like, because ML64 doesn't implement ASSUME for 64-bit code, and I haven't found a convenient way of getting RSP-based locals without using STRUCTs. UASM would allow me to code more like NoCforMe. I will probably make a UASM version later.
I have kept the 32-bit and 16-bit data, converting only handles and pointers to 64-bits. I've gotten rid of all the PUSHes and POPs to support RSP-based locals. I've changed all MOV reg, OFFSET to LEA reg, and split .data addresses from registers adding to addresses. because most .data addresses must be 32-bit OFFSETs or RIP-relative. (RIP-relative addresses cannot have base or index registers!) I've needed to store register arguments to local storage.
That's most, if not all, of the things I needed to take care of.
Game of Life: GOL64v1.zip
Hi tenkey, I had to make one small alteration, adding PSDWORD typedef QWORD before include masm64rt.inc
Did the original ding every time a square is clicked? I can't remember.
Quote from: tenkey on August 23, 2024, 06:27:53 AMI have kept the 32-bit and 16-bit data, converting only handles and pointers to 64-bits. I've gotten rid of all the PUSHes and POPs to support RSP-based locals. I've changed all MOV reg, OFFSET to LEA reg, and split .data addresses from registers adding to addresses. because most .data addresses must be 32-bit OFFSETs or RIP-relative. (RIP-relative addresses cannot have base or index registers!) I've needed to store register arguments to local storage.
I've got to thank you for that. This confirms for me that I never, ever want to touch 64-bit code. Pain in the ass.
Just curious: why did you feel compelled to move this into 64-bit land?
Quote from: tenkey on August 23, 2024, 06:27:53 AMsupport RSP-based locals
A stack frame is not a bad idea if you have many locals, and use them often. The rbp encodings are shorter, and you can use push & pop where needed:
8B45 14 | mov eax,[rbp+14] |
48:8B45 14 | mov rax,[rbp+14] |
8B4424 14 | mov eax,[rsp+14] |
48:8B4424 14 | mov rax,[rsp+14] |
Quote from: NoCforMe on August 23, 2024, 03:06:18 PMJust curious: why did you feel compelled to move this into 64-bit land?
I'm interested in 64-bit and I've known about Conway's Life for a long time. People have been creating patterns on very large playing fields. That calls for the ability to zoom the display in and out, as some visual effects can only be seen from a macro view. The large amount of data means speed and compactness become important. My effort is just a tiny poke into this world.
I suppose I should make a UASM version. It will break MASM compatibility. But it would be cleaner.
Quote from: sinsi on August 23, 2024, 08:56:25 AMHi tenkey, I had to make one small alteration, adding PSDWORD typedef QWORD before include masm64rt.inc
Did the original ding every time a square is clicked? I can't remember.
Before? My version of masm64rt.inc doesn't require it. That's why I put the missing HPEN and HFILE definitions
after the include.
I can't run the original .exe from my Windows 11 system because of AV. My rebuilt 32-bit version doesn't ding on Windows 11.
Quote from: tenkey on August 24, 2024, 02:11:41 AMI suppose I should make a UASM version. It will break MASM compatibility.
Imagine that. And here I thought that uasm was supposed to be masm compatible. :rolleyes:
Kudos though, on converting it to 64 bit.
Quote from: jj2007 on August 23, 2024, 05:26:22 PMQuote from: tenkey on August 23, 2024, 06:27:53 AMsupport RSP-based locals
A stack frame is not a bad idea if you have many locals, and use them often. The rbp encodings are shorter, and you can use push & pop where needed:
8B45 14 | mov eax,[rbp+14] |
48:8B45 14 | mov rax,[rbp+14] |
8B4424 14 | mov eax,[rsp+14] |
48:8B4424 14 | mov rax,[rsp+14] |
Interesting.
Quote from: jj2007 on August 23, 2024, 05:26:22 PMand you can use push & pop where needed:
If you know what you are doing :biggrin:
Dangerous otherwise.
Quote from: tenkey on August 24, 2024, 02:11:41 AMQuote from: NoCforMe on August 23, 2024, 03:06:18 PMJust curious: why did you feel compelled to move this into 64-bit land?
I'm interested in 64-bit and I've known about Conway's Life for a long time. People have been creating patterns on very large playing fields. That calls for the ability to zoom the display in and out, as some visual effects can only be seen from a macro view. The large amount of data means speed and compactness become important. My effort is just a tiny poke into this world.
I suppose I should make a UASM version. It will break MASM compatibility. But it would be cleaner.
Kudos for 64 bit version
I am interested in 128bit SIMD and MMX later SSE2 instructions are made for speedup image processing and if user has 4k screen ,option for use that kind of screen resolution and padd instructions you can add together number of neighbouring pixels in parallel
Quote from: sinsi on August 24, 2024, 12:11:38 PMQuote from: jj2007 on August 23, 2024, 05:26:22 PMand you can use push & pop where needed:
If you know what you are doing :biggrin:
Dangerous otherwise.
AFAICT it's only a real concern if you want to handle exceptions or pass exceptions back to C++ code. An interesting question is if UASM PROC args, USES, LOCALs, INVOKE, and RET properly work together--involving issues I had to consider when constructing STRUCTs for local (stack) data.
If you ignore shadow/spill space, ML64 will correctly setup LOCAL variables, PROC args and USES via RBP.
You still need to spill the first 4 args if needed, though.
Quote from: tenkey on August 25, 2024, 01:52:38 AMAn interesting question is if UASM PROC args, USES, LOCALs, INVOKE, and RET properly work together--involving issues I had to consider when constructing STRUCTs for local (stack) data.
The automatic generation of STACKBASE:RSP code is broken, so there will not be a UASM version of Life. I have some ideas for fixing it.
There is an almost MASM-compatible interface with STACKBASE:RBP (default), but that's not what I'm aiming for.