Game of Life Rework

[Brandon502]

Removed randomness. Improved infinite pattern detection. Added color mutation slider, wrap option, and overlay option.

[Brandon502]

I am unable to test the All Colors option. I tried to keep that option available, but can not confirm if it works correctly. Tested the new infinite pattern detection a ton. The crc method isn't perfect, as in it may take an extra loop or two to detect, but I have yet to see it fail.

The overlay option requires more memory to achieve. The first commit doesn't have overlay and uses roughly the same amount of memory as the original.

[ewoudwijma]

Hi Brandon, thx for this PR! Looks good from a first look at the code. @softhack007 , can you also take a look? Regards, Ewoud

[Brandon502]

@softhack007 I committed a low memory version. I focused on getting memory down, everything appears to all function the same. Dominant color is affected slightly but not really noticeable. This version uses 2 bits per cell/pixel. Without the overlay option it is just 1 bit. I added two functions to help get and set bit values. I didn't know if there were anything similar already built in so I just made my own for testing. I haven't reworked repeatDetection yet.

[ewoudwijma]

Hi Brandon, thx for your great work on GOL! I am a bit busy so look from the sideline, but happy to test it out soon!

[softhack007]

Hi Brandon, sorry we kept you waiting for so long... We have decided to add your effect into the next MM release, which is scheduled for May 15th (tentatively).

I think that you did a great job in reducing the memory footprint, thanks 👍

So we'll try to do some testing this week. I'll make a start with some new review comments.

[Brandon502]

@softhack007 found and pushed the updated struct version. I still need to look at the helper functions and add comments on the pauseFrames and generations aliases. Also need to incorporate a fail safe check that I have run into on a 24x16 matrix that can produce an insanely long repeating pattern that is undetected.

[Brandon502]

Made the helper functions static and removed arraySize which wasn't used. Added comment regarding aux0 and aux1. This alias can be removed if needed, was just to help improve readability while coding. Fail safe was added to disable wrap on every generation with a multiple of 1500. This is a very niche case that will likely only apply to very specific rectangle matrices. I have already seen this fail safe work on a 24x16 display.

[Brandon502]

https://github.com/MoonModules/WLED/assets/105077712/8d228edd-25d8-4dda-a35f-bfb627681d37

Quick example video showing game of life overlayed on rainbow background. You can see the game pause briefly at the end of a game and start.

[ewowi]

I tested latest commit (by migrating it to StarLeds ;-)

https://github.com/MoonModules/StarLeds/commit/41b7c7cae649cd5303aec9b6fd54f2186e50d17c

My comments / changes /questions, although you should read it in StarLeds context:

StarMod specific simplifications

• No matrix testing
• No struct as StarMod has a simpler data bind mechanism (?)
• Used leds.size.x/y instead of row/col
• Aux0,1, step, etc in data bind
• No overlay functionality in effects

WLED specific

• No struct might be needed if done in binding ???
• Added fill black color at start/reset
• Used CRGB instead of RGBW32
• Byte instead of uint8_t for (future)cells
• set/getBitValue simpler possible if using bytes?
• Use byte type in crc (call)?

Result is not as it should but probably something went wrong in conversion (too many pixels coloured ???)

https://github.com/MoonModules/WLED/assets/138451817/4efed40c-2f39-4c31-b469-475e713180a6

Any idea what could cause this?

[ewowi]

Regarding a more readable solution for a bit array:

http://www.gotw.ca/gotw/050.htm

vector(bool) uses one bit per bit !

this might be considered as it is more readable, no set/get functions needed and ‘maybe’ it’s faster.

so a nice to have , but in case of low performance worth the try

[ewowi]

Memcpy third parameter is Number of bytes to copy.

so don’t you copy 8 times as much ?

… okay, I got confused by sizeof(byte). As sizeof returns the number of bytes, you are asking how many bytes is a byte which in this universe is always one isn’t it ? So we could remove sizeof(byte)?

[ewowi]

And what about pauseFrames? Can you explain what it does what normal return FRAMETIME is not doing? (It looks to me that an effect should not manage their timings but the effect system should do)

[Brandon502]

And what about pauseFrames? Can you explain what it does what normal return FRAMETIME is not doing? (It looks to me that an effect should not manage their timings but the effect system should do)

This was one of the things I added last and it can definitely be done in a less confusing manor. It's basically stops the game from ending/starting and allows you to see the starting and ending pattern before it starts/resets. Pauses updates for about a second. Before this the game immediately restarted a new game which made knowing when a new game started and debugging difficult. It was added in a way that game speed didn't effect how long the pause was. I can't think of a way to implement this without an extra variable, any suggestions?

[Brandon502]

Memcpy third parameter is Number of bytes to copy.

so don’t you copy 8 times as much ?

… okay, I got confused by sizeof(byte). As sizeof returns the number of bytes, you are asking how many bytes is a byte which in this universe is always one isn’t it ? So we could remove sizeof(byte)?

Yeah sizeof(byte) seems redundant. Didn't catch that when I converted everything to use bits.

Regarding a more readable solution for a bit array:

http://www.gotw.ca/gotw/050.htm

vector(bool) uses one bit per bit !

this might be considered as it is more readable, no set/get functions needed and ‘maybe’ it’s faster.

so a nice to have , but in case of low performance worth the try

I haven't run into performance issues yet with current implementation, but I've only tested on esp32s. This may be an option, I can't really wrap my head on how to implement it yet though.

[Brandon502]

I tested latest commit (by migrating it to StarLeds ;-)

MoonModules/StarLeds@41b7c7c

My comments / changes /questions, although you should read it in StarLeds context:

StarMod specific simplifications

* No matrix testing
* No struct as StarMod has a simpler data bind mechanism (?)
* Used leds.size.x/y instead of row/col
* Aux0,1, step, etc in data bind
* No overlay functionality in effects

From your video it looks like dead cells are not disappearing. I'll have to look at the code and test it, but it looks like something may have gone wrong when removing overlay functionality. You can get the same effect in wled if you enable overlay without a background segment.

WLED specific

* No struct might be needed if done in binding ???

The version before this didn't use a struct and just had different variables. Either method is fine with me. Struct seems a bit more organized/readable.

* Added fill black color at start/reset

Fill black I don't believe is needed. When the game starts if overlay is off it sets dead cells to the background color.

* Used CRGB instead of RGBW32

Not sure if this is referencing wled or not, but I can swap to CRGB instead of RGBW32. I kept all of your RGBW code to keep the all colors option available.

* Byte instead of uint8_t for (future)cells
* set/getBitValue simpler possible if using bytes?
* Use byte type in crc (call)?

I'm not sure the differences between uint8_t and byte so this change may be better.

[Brandon502]

MoonModules/StarLeds@41b7c7c

@ewowi line 1440 needs to be converted to something like leds.setPixelColor(leds.XY(x,y), backgroundColor); Haven't tested it yet, but that is likely causing it to misbehave.

Edit: Tried testing on an esp32, but the fixture preview window does not work on my end. The pin viewer works though.

[Brandon502]

https://github.com/MoonModules/WLED/assets/105077712/73e84979-6bba-414a-9395-6bfbc7e16896

Stress tested on large matrices. Seems to work up to 63x63, hard to tell performance through live view though. 64x64 causes a integer division by 0 error.

[softhack007]

Used CRGB instead of RGBW32

Not sure if this is referencing wled or not, but I can swap to CRGB instead of RGBW32. I kept all of your RGBW code to keep the all colors option available.

Hi, I think for WLED-MM it's better to use RGBW32. We support white channel strips (RGBW) and CRGB cannot handle 4 color channels.

[ewowi]

Hi Brandon, your code is fine, no need to change anything, except remove sizeof(byte) as it is always 1. And you are right, I got it working with your suggestion 🙏

Softhack, Rgbw is fine too, although the fourth parameter is 0 but leave it as is.

my comments where mainly valid in a StarMod context.

so, if softhack is fine, and saw it working 🙂we can merge it

[Brandon502]

Hi Brandon, your code is fine, no need to change anything, except remove sizeof(byte) as it is always 1. And you are right, I got it working with your suggestion 🙏

Softhack, Rgbw is fine too, although the fourth parameter is 0 but leave it as is.

my comments where mainly valid in a StarMod context.

so, if softhack is fine, and saw it working 🙂we can merge it

Hey, glad it is working in StarMod. Now you just have to edit the neighbor loop to allow 3D cubes :D. Wish I could figure out how to get it working properly on my end so I can play around with things. Can't connect WiFi and preview feature doesn't work.

[ewowi]

@Brandon502 ,

Yeah 3D would be a think, also a giant cube needed !!! What is the largest ws2812 3D Cube existing?

There was a guy called Trackerr on Discord who reported something similar, which I just turned into an issue: https://github.com/ewowi/StarBase/issues/55. Is this related? Please add to the issue if you have a different situation

[Brandon502]

@Brandon502 ,

Yeah 3D would be a think, also a giant cube needed !!! What is the largest ws2812 3D Cube existing?

There was a guy called Trackerr on Discord who reported something similar, which I just turned into an issue: ewowi/StarBase#55. Is this related? Please add to the issue if you have a different situation

Largest cube I've seen is just the 16x16 ws2812b panels. The bigger panels just get too expensive to buy multiple of. Just tried starleds again on a different esp32 and no dice. I'll make a post there.

[ewoudwijma]

Hi @Brandon502 ,

I see quite often that gol will repeat itself endlessly. Is that by design?

https://github.com/MoonModules/WLED/assets/1737159/5fc70473-3b35-475c-bdb8-57700798fde8

[Brandon502]

Hi @Brandon502 ,

I see quite often that gol will repeat itself endlessly. Is that by design?

trim.45DA33E0-E7D6-48B3-BA98-A67907C75AC7.MOV

I played with this last night. Starmod version is pretty broken lol. I'm slowly trying to debug it. Everything looks right in the code so it's frustrating. One thing is that generation is not actually being increased by generation++; changing to generation += 1; fixes that. No clue why. Without generation increasing repeat detection is basically disabled.

[ewowi]

Ah, sorry for the inconvenience 🤭, reason is that generation is a bind var so is a pointer so to increase it we need to do (generation)++ instead of generation++.

I changed that and now it is much better! (https://github.com/MoonModules/StarLeds/commit/940e91ad0ccf036cb1fb7a3121d4f38660080b3b)

PS: you have to set blending to 0 to have pixels fading away - This is the way of overlaying in StarLeds - idea is to do that outside effect code, but I need to think about it a bit more (or if you have ideas ;-) )