Conway's Game Of Life

[retepsnikrep]

last time i played with "life" i never found a way to detect a stable repetitive cycling pattern.
are you determining if boring stuck patterns ensue ?

Currently i'm using three things.

1) A simple maximum number of generations reset limit (500). That catches everything.

2) A simple live cell counter. If it's zero then it resets.

3) A pseudo checksum which seem to work quite well.

A word variable to which the address of every populated cell is added, it may overflow many times, and after all 1024 cells have been generated/examined you end up with a number.
It also calculates the checksum for the next generation and if it matches the previous generation then it probably means we have a stuck pattern and resets.

I've been testing this for thousands of patterns and generations now and it works well.
It only falls back on the hard generation limit with huge repeating patterns that cycle over several generations.
It detects small oscillators and stuck patterns etc quite well.

I appreciate it is possible for two patterns to have the same checksum but the odds must be very very small.

Cross post with Richard LOL!! Basically what I'm doing but I'm not quite as clever as the 'Life' experts.

[retepsnikrep]

Thanks Henrick..

If the array transform only takes call it ~5ms per generation then at 15hz it's using 75ms in a second.
Roughly equivalent to one extra generation per second. Getting close to not much return for our efforts..

Do we think we can directly evaluate the Neopixel array with it's weird layout.. ?

I'm going to set my display up with some timing pins today and have a fiddle about.

Thanks for all the interesting replies.

[tumbleweed]

To expand a little more on Henrick's last post, this gets it down to 3.51ms:

tLED VAR BYTE

FOR Row = 0 to 31         ' Cycle thru 32 rows
     
    TempW = ROW * 32       ' Precalculate this instead of doing it every time thru the loop

    InPtr = TempW
    FOR Col = 0 To 30 Step 2
        tLED = lednew[InPtr]
        led[InPtr] = tLED
        OutPtr = InPtr
        IF tLED > 0 THEN
           NeoLed(OutPtr) = tLED
           alive = alive + 1
           dead = dead + InPtr
        ELSE
            NeoLED(OutPtr) = 0
        ENDIF
        InPtr = InPtr + 2
    NEXT
    
    InPtr = TempW + 1
    FOR Col = 1 To 31 Step 2    ' Odd rows
        tLED = lednew[InPtr]
        led[InPtr] = tLED
        OutPtr = (TempW) + (31-Col)   'Reversed order
        IF tLED > 0 THEN
           NeoLed(OutPtr) = tLED  
           alive = alive + 1
           dead = dead + InPtr
        ELSE
           NeoLED(OutPtr) = 0
        ENDIF
        InPtr = InPtr + 2
    NEXT
NEXT

You could get similar reductions in the other sections of code by eliminating multiple evaluations of things like 'led[CntMinus1]'.
Every time it sees an array access using a variable it has to recompute the value of where it's pointing to.

If you assign the array value to a temp byte

tLED = led[CntMinus1]

and use that it saves a bunch of code/time. Obviously that only works for the RHS of an equation or a test, not the LHS.