>> I don't get it. That's a nice compression for the average and best cases,
>> but the kernel and algorithm have to be able to handle the worst case.
>> What if a large-scale stable situation develops - all stable patterns (2x2
>> blocks, 6-cell ovals, etc, 3-in-a-row alternators, etc) separated by empty
>> gaps 2-4 cells wide?
>
>
>Then my proposed implementation could not handle it. This is a limitation I
>was aware of, and am prepared to put up with. It won't be perfect - but
>will be good enough for most cases. I doubt, under most circumstances, it
>would ever be noticed.
How exactly do you "not handle" it - just drop the data from the last part
of the board that won't fit into the storage? Still doesn't sound
appealing to me - it may just be the effects of my almost-completed CS
degree, but I really don't like such an elegant process as Life being
affected functionally (in this case, actively corrupted) by the RAM of its
simulator system.
A closer look shows that for the generation processing, one needs to store
one row of the shorter dimension of the rectangle plus 2 cells. You could
do a 32 x 30 uncompressed and still have scratch space for the processing.
To get the 40 x 64 that you wanted, you have to achieve a 2.666:1 (8:3)
compression ratio (and that would also have a weird aspect ratio on screen
in excess of 2:1.)
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
