Game of Life

[daydreamer]

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

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

[NoCforMe]

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

Everything you listed is total overkill for this very simple "game".

[zedd151]

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

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. 

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

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

[NoCforMe]

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

[daydreamer]

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

[NoCforMe]

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.

[tenkey]

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: You cannot view this attachment.

[sinsi]

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.

[NoCforMe]

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.

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?

[jj2007]

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

Code Select Expand

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]                    |

[tenkey]

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

[tenkey]

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.

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.

[zedd151]

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

Kudos though, on converting it to 64 bit.

[tenkey]

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

Code Select Expand

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.

[sinsi]

and you can use push & pop where needed:

If you know what you are doing 
Dangerous otherwise.