Yup, just follow this link: https://www.cemetech.net/programs/index.php?mode=file&id=1445

Congratulations on releasing this, Merthsoft! Your Game of Life games get more impressive on each platform you explore, and this is no exception. I hope that other programmers will try to emulate the polish and precision you put into this.

Fixed a memory leak. New version at the same download link:
https://www.cemetech.net/programs/index.php?mode=file&id=1445

Necro Post:
Update to this program is needed, your C Libraries required to run this are way out of date. This still requires GraphC which was discontinued a few months ago. This is a cool program, but it's a pain to run with old, bugy libraries. (it caused a BSoD on a calculator, whoever heard of that? ) If this could be updated to use the new C Libraries, I'm sure many people would appreciate it.

John Conway, the namesake of Conway's Game of Life, passed away April 11, 2020. As a show of appreciation for an amazing mind, I am reviving this project to support the latest release of the libraries, as well as adding new features. Notably, I'm adding a "stamp" feature which will allow you to choose pre-made stamps, such as the classic Glider, shown here:



This current build is available here:
http://merthsoft.com/GOL.8xp
Upload to archive will come when I have more stamps built out.

Source is available here:
https://bitbucket.org/merthsoft/gol-84-ce/

Please also enjoy a javascript Game of Life I made some time ago here:
http://merthsoft.com/gol/

Nice! How many stamps are you planning on adding?

I'm aiming for 10-15 per rule set, with the ability to place ones from other rule-sets as well (lots of overlap in the life-but-extra rules). I'm also adding a basic Apgcode and RLE parsing so you can add your own and save them, as well as the ability to convert a section of the board into a stamp so users can draw their own, or export anything interesting they find to Apgcode. This has the advantage of making this program compatible with Golly, Catagolue and other popular tools.

*bump*

Took a side-trip to work on double-buffering to big boards render more smoothly:

What about different colors for cells in different states.

For example:
green cell: The cell has just been born.
blue cell: The cell has been alive for more than one generation.
red cell: the cell will die in the next generation.

But I don`t know how such a feature is to compare with no decreased speed.
The calculators can`t calculate so fast.

Would it be possible to use a TI-BASIC or some other on-calc editable program to define custom per-cell rules? This would also enable the user to take more direct control over the cells (by using getKey), possibly enabling the development of actual nonzero-player games.

Or could you please post or link to the source code?

TI-BASIC would be incredibly slow for this - there are thousands of tiles on-screen at once, you'd have to wait for each tile to be evaluated. It would be only slightly faster than writing the entire program in TI-BASIC.

[quote=I]...or some other on-calc editable program to define custom per-cell rules?[/quote]

I know it would be incredibly slow. But there certainly ought to be some way to define custom rulesets for more than two states (like JvN 29). The reason I said TI-BASIC is because most people know it. My idea was to have some sort of "Rule" language, more or less identical to TI-BASIC but without any I/O tokens. It's compiled to eZ80 assembly or possibly something more akin to ICE on GoL startup (or whenever you ype in a new ruleset "program" in settings). Irealize this isn't a terribly well-articulated idea, but it might work.

It might.

It's pretty slow compared to other cellular automata CE programs I've seen, is there a lot of if statements in the main loop slowing it down? If so, I would suggest converting a bunch of them to variables, since it will free up your code and make it less cluttered. There seems to be a bunch of features, and if you make it so it includes all of one feature in one go, then you won't have a bunch of if statements, if that makes any sense. (e.g., maybe special functions for the different topologies instead of putting a lot of code inside a bunch of different if statements/functions.)