Pattern viewer for forum threads

[rowett]

Build 663 is deployed here. I haven't deployed it to the forum yet since it contains a couple of complex changes:

1. The grid can grow independently in the X and Y direction (which reduces memory usage for some patterns)
2. There should be less janking during normal playback

A full list of fixes and changes in build 663 is available here.

Please let me know if there are any issues with normal functionality. If no reports I'll push it to the forums/wiki etc. in a few days.

[GUYTU6J]

For the cell colors of each states in the "none" rule, how are they defined? What will they look like when written out in the rule table format?
The question is inspired from the following post elsewhere:

Here's a rule that does nothing.

Code: Select all

@RULE draw

@TABLE
n_states:125
...

[erictom333]

For the cell colors of each states in the "none" rule, how are they defined? What will they look like when written out in the rule table format?
The question is inspired from the following post elsewhere:

Here's a rule that does nothing.

Code: Select all

@RULE draw

@TABLE
n_states:125
...

For the rcord, my rule used every color in a 5R × 5G × 5B cube, hence the 125 states.

[rowett]

For the cell colors of each states in the "none" rule, how are they defined? What will they look like when written out in the rule table format?

Code: Select all

x = 16, y = 16, rule = none
.ABCDEFGHIJKLMNO$
PQRSTUVWXpApBpCpDpEpFpG$
pHpIpJpKpLpMpNpOpPpQpRpSpTpUpVpW$
pXqAqBqCqDqEqFqGqHqIqJqKqLqMqNqO$
qPqQqRqSqTqUqVqWqXrArBrCrDrErFrG$
rHrIrJrKrLrMrNrOrPrQrRrSrTrUrVrW$
rXsAsBsCsDsEsFsGsHsIsJsKsLsMsNsO$
sPsQsRsSsTsUsVsWsXtAtBtCtDtEtFtG$
tHtItJtKtLtMtNtOtPtQtRtStTtUtVtW$
tXuAuBuCuDuEuFuGuHuIuJuKuLuMuNuO$
uPuQuRuSuTuUuVuWuXvAvBvCvDvEvFvG$
vHvIvJvKvLvMvNvOvPvQvRvSvTvUvVvW$
vXwAwBwCwDwEwFwGwHwIwJwKwLwMwNwO$
wPwQwRwSwTwUwVwWwXxAxBxCxDxExFxG$
xHxIxJxKxLxMxNxOxPxQxRxSxTxUxVxW$
xXyAyByCyDyEyFyGyHyIyJyKyLyMyNyO!
[[ GRID ]]

Help->Info->Colours will show you the list of RGB values for the none rule.

[muzik]

There's some other oddities I've spotted in the none rule: the population count only seems to count state 1 (again likely due to the Generations leftovers), and the color menu doesn't list all state colors if not all states are present in the pattern (open the following pattern, select all, random fill, then go to Help > Info > Colours)

Code: Select all

x = 54, y = 30, rule = none
o29$53bo!

There's plenty of other oddities in this vein but I want to hold off on reporting such things until the next version officially comes out.

[rowett]

Hello LifeViewer users!

I'm considering merging the steps per second and generations per step controls.

I have now created a prototype of the proposed change here.

There is now a single slider that goes from [1/s -> 59/s -> 1x -> 64x] speeds. To the left of the slider is a button [1x] which resets the speed to 1x.

newcontrols.png (13.86 KiB) Viewed 2154 times

The minimum Viewer width is slightly wider allowing the inclusion of the reverse playback button (greyed out if not applicable to the current rule).

Please let me have your feedback on this proposed change!

Note: there may be functionality that is broken in this build. It's still a work in progress.

[muzik]

I have now created a prototype of the proposed change here.

Note: there may be functionality that is broken in this build. It's still a work in progress.

An incredibly minor sighting to start off with: starting patterns with GPS 2 will have only odd generations displayed rather than even generations as is the case in current builds, resulting in a permanently on background as opposed to permanently off for the following strobing pattern:

Code: Select all

x = 10, y = 8, rule = R1,C2,S4-5,B0-2:T50,50
2b2o$5b4o$ob2o$ob3o4bo$ob3o4bo$ob2o$5b4o$2b2o!
[[ GPS 60 STEP 2 NOTHROTTLE ]]

[rowett]

An incredibly minor sighting to start off with: starting patterns with GPS 2 will have only odd generations displayed

Fixed, thanks.

[muzik]

Running this, changing the rule to Life inside the viewer and then checking Help > Info > Pattern lists 255 different alive states:

Code: Select all

x = 16, y = 16, rule = none:P16,16
.ABCDEFGHIJKLMNO$PQRSTUVWXpApBpCpDpEpFpG$pHpIpJpKpLpMpNpOpPpQpRpSpTpU
pVpW$pXqAqBqCqDqEqFqGqHqIqJqKqLqMqNqO$qPqQqRqSqTqUqVqWqXrArBrCrDrErFrG
$rHrIrJrKrLrMrNrOrPrQrRrSrTrUrVrW$rXsAsBsCsDsEsFsGsHsIsJsKsLsMsNsO$sP
sQsRsSsTsUsVsWsXtAtBtCtDtEtFtG$tHtItJtKtLtMtNtOtPtQtRtStTtUtVtW$tXuAuB
uCuDuEuFuGuHuIuJuKuLuMuNuO$uPuQuRuSuTuUuVuWuXvAvBvCvDvEvFvG$vHvIvJvKvL
vMvNvOvPvQvRvSvTvUvVvW$vXwAwBwCwDwEwFwGwHwIwJwKwLwMwNwO$wPwQwRwSwTwUwV
wWwXxAxBxCxDxExFxG$xHxIxJxKxLxMxNxOxPxQxRxSxTxUxVxW$xXyAyByCyDyEyFyGyH
yIyJyKyLyMyNyO!

I've also noticed that in neither case is state 0 listed.

For these patterns, going to Help > Info > Colours displays a value for bounded that does not correspond with what is actually seen, due to available state colors being exhausted:

Code: Select all

x = 1, y = 1, rule = none:P16
o!

Code: Select all

x = 1, y = 1, rule = /2/193:P16
2o!

Could the value displayed be made to be what it was overwritten with, possibly with a message next to Bounded saying just that (that the bounded color setting was overwritten due to too many states)?

Another thought I've had: it might be possible to decrease the "grid size" even more for bounded grids, given that those regions will never be accessible. The help menu suggests that is not the case yet.

[rowett]

Running this, changing the rule to Life inside the viewer and then checking Help > Info > Pattern lists 255 different alive states

The state names are now fixed. Note here that this is information on the pattern, not what the rule supports.

I've also noticed that in neither case is state 0 listed.

Correct, a count of the dead cells is not provided for any rule type.

For these patterns, going to Help > Info > Colours displays a value for bounded that does not correspond with what is actually seen, due to available state colors being exhausted

Fixed, thanks.

Another thought I've had: it might be possible to decrease the "grid size" even more for bounded grids, given that those regions will never be accessible. The help menu suggests that is not the case yet.

The minimum grid size is 512x256. It won't get any smaller due to how the tiling system works.

[muzik]

Rotating the grid to a desired angle such as 45 degrees can be difficult and it's very likely that the rotation will be off by a minuscule amount, introducing minor visual imperfections. Could a button of some sort be added to round the grid's rotation to the nearest multiple of 7.5 degrees or so (similar to the 1x button we're getting) such that important angles are easier to achieve?

[Ian07]

The default play speed appears to have been increased from 60 to 100 generations per second; however, the first half of the slider has not been updated to reflect this, so, for example, setting the speed to "3/s" actually sets it to 5 generations per second.

EDIT: After timing it out with a metronome the speed I'm getting seems to be around 96 gps.

[muzik]

Could the "currently selected for drawing" buttons/slider be made to be visible and selectable when select is the current mode, rather than only with draw, so it's easy to see and change what state is random filled with?

There's also some minor pixel bugs which are visible on greyed-out buttons on desktop - I can get pictures of it in action if desired.

[rowett]

There's also some minor pixel bugs which are visible on greyed-out buttons on desktop - I can get pictures of it in action if desired.

Please do.

[rowett]

The default play speed appears to have been increased from 60 to 100 generations per second; however, the first half of the slider has not been updated to reflect this, so, for example, setting the speed to "3/s" actually sets it to 5 generations per second.

This should be fixed now.

LifeViewer's update speed is based on the monitor refresh rate. When LifeViewer starts it measures the update rate and this becomes "1x" playback speed. For me this is 60 generations/second since my monitor refreshes at 60Hz.

Assuming a refresh rate of 60Hz the playback speed control will let you set playback speeds from 1 generation/second to 59 generations/second, and then from 1x (which means 1 generation every 1/60th of a second) to 64x (64 generations every 1/60th of a second).

If your monitor refreshes at 75Hz then you'd get 1/s to 74/s, and then 1x (1 generation every 1/75th of a second) to 64x (64 generations every 1/75th of a second).

Help->Info->Display will show you the measured Refresh rate.
Settings->Advanced->Frame Times will show the current actual update rate (fps) and load.

Note that the playback speed is just a target. If the device is too slow and/or the pattern is very large LifeViewer may be unable to meet the specified target. At which point the playback speed control will go red.

[muzik]

There's also some minor pixel bugs which are visible on greyed-out buttons on desktop - I can get pictures of it in action if desired.

Please do.

Screenshots are coming up soon but the manifestation of this bug seems inconsistent.

Anyway, another bug: opening the bottom viewer deletes the reverse button and 1x button from all other viewers until the page is refreshed:

Code: Select all

#CXRLE Gen=-99990
x = 4, y = 4, rule = M0,3,10,2,5,1,6,7,12,9,8,11,4,13,14,15
$2bo$2bo$3o$3bo!

Code: Select all

x = 10, y = 7, rule = 23/3History
4.D.H$2.BCFEKI$.AC2F3KJ$A2CHIN.NK$.ACFAH.2NL$2.3A3.M$3.A!

[rowett]

opening the bottom viewer deletes the reverse button and 1x button from all other viewers until the page is refreshed

Fixed, thanks!

[muzik]

Some hexagonal OT aliases from this video:

Code: Select all

2456/23456/4H : Gliders 1
134/2345/5H : Gliders 2
1/123456/15H : Ripples
2/2/3H : Swimming Fish 1
24/24/3H : Swimming Fish 2
12456/234/20H : Waves

We're probably quite overdue on an aliases update since the last one was from August 2020 - I'll need to rake through pretty much every OCA thread started since then to be complete.

----

Would it be possible to have HROT notation accept isotropic non-totalistic rules if the neighbourhood in question has 4 corner cells and 4 edge cells just like the Moore neighbourhood has? This would allow for lemon41625's R2 Far Corners and R3 Far Edges isotropic non-totalistic rulespaces (see this thread for examples) to be notated for use in, and investigated with LifeViewer, as well as any other desired neighbourhood provided that it's comprised of four corner cells and four edge cells.


For example, the following would be a double-skew version of tlife, where all constituent cells are separated by one cell each:

Code: Select all

x = 29, y = 23, rule = R2,C0,S2-i,3,4q,B3,N@A82415
obobo2$obobo2$6bo12$o9bobo2$o3bo5bobo11bobobo2$obo7bobo3bo9bo2$14bo!

The equivalent pattern in double-skew Life would be this:

Code: Select all

x = 29, y = 23, rule = R2,C0,S2-3,B3,N@A82415
obobo2$obobo2$6bo12$o9bobo2$o3bo5bobo11bobobo2$obo7bobo3bo9bo2$14bo!

And the normal, non-decompressed equivalents in normal tlife and normal life:

Code: Select all

x = 15, y = 12, rule = B3/S2-i34q
3o$3o$3bo6$o4b2o$obo2b2o5b3o$2o3b2obo4bo$7bo!

Code: Select all

x = 15, y = 12, rule = B3/S23
3o$3o$3bo6$o4b2o$obo2b2o5b3o$2o3b2obo4bo$7bo!

These would be supported by this notation as it can be clearly seen that the neighbourhood in question has four edges and four corners:

Code: Select all

x = 5, y = 5, rule = none
obobo2$o3bo2$obobo!

[rowett]

Some hexagonal OT aliases from this video:
...
We're probably quite overdue on an aliases update since the last one was from August 2020 - I'll need to rake through pretty much every OCA thread started since then to be complete.

I'm now thinking that for aliases to be a "good thing" they need to be shared across the common tools. Otherwise they become annoying since people might post a pattern using an alias and find it gets rejected when they paste it into another tool.

Would it be possible to have HROT notation accept isotropic non-totalistic rules if the neighbourhood in question has 4 corner cells and 4 edge cells just like the Moore neighbourhood has?

It's a lot of work for little gain (i.e. I'm not likely to implement it). The expanded versions are functionally identical to the non-expanded versions so there's no research benefit.

[muzik]

Would it be possible to have HROT notation accept isotropic non-totalistic rules if the neighbourhood in question has 4 corner cells and 4 edge cells just like the Moore neighbourhood has?

It's a lot of work for little gain (i.e. I'm not likely to implement it). The expanded versions are functionally identical to the non-expanded versions so there's no research benefit.

That's only because I'm using one with functionally identical behaviour as an example, since they'd be one of many allowed. The following two neighbourhoods (R2 Far Corners and R3 Far Edges), which would also be permitted by this notation, exhibit completely unique behaviour, and are the ones lemon41625 has been investigating:

Code: Select all

x = 19, y = 7, rule = none
15bo$o3bo$2bo11bobo$bobo8bo5bo$2bo11bobo$o3bo$15bo!

An example (5,0)c/360 spaceship in a non-totalistic R2 Far Corners rule:

Code: Select all

x = 6, y = 4, rule = R2,C2,S0,1c,2-ik,3aq,4cejnq,5cjkny,6i,7c,8,B2eik,3ciqy,4ryz,5aenq,6cin,7e,N@891891
.A.A.A.$A.A.A.A$A.3A.A$3.A3.$3.A3.$!

lemon41625's original notation (which I believe both CAViewer and lifelib use) simply takes a normal isotropic non-totalistic rulestring and appends /NFC or /NFE to the end for R2 Far Corners or R3 Far Edges respectively. I'm proposing that we use a modified HROT string instead since instead of being locked into range-1 Moore, range-2 Far Corners and range-3 Far Edges, we can instead specify arbitrary neighbourhoods so long as they fit our 8-cell restrictions, and as such all of these neighbourhoods (and more) become possible isotropic non-totalistic neighbourhoods (some of them trivial, as discussed earlier, but many of them not):

Code: Select all

x = 91, y = 91, rule = none
o9bo9bo9bo9bo9bo9bo9bo9bo4bo4bo$65bo$45bo$25bo$5bo$4bobo16bo3bo14bo5bo
12bo7bo10bo9bo$5bo$25bo$45bo$65bo$o9bo9bo9bo9bo9bo9bo9bo9bo4bo4bo10$
85bo$81bo7bo$o7bo11bo7bo11bo7bo11bo3bo3bo$44bo$24bo$4bo75bo9bo$3bobo
16bo3bo14bo5bo12bo7bo$4bo$24bo$44bo36bo7bo$o7bo11bo7bo11bo7bo11bo3bo3b
o16bo10$85bo2$64bo17bo5bo$61bo5bo$o5bo13bo5bo13bo2bo2bo$23bo56bo9bo$3b
o56bo7bo$2bobo16bo3bo14bo5bo$3bo78bo5bo$23bo37bo5bo$o5bo13bo5bo13bo2bo
2bo17bo20bo10$85bo2$64bo$83bo3bo$43bo18bo3bo$41bo3bo34bo9bo$o3bo15bobo
bo35bo7bo$2bo37bo5bo36bo3bo$bobo16bo3bo37bo3bo$2bo38bo3bo$o3bo15bobobo
18bo20bo20bo10$85bo2$64bo2$43bo40bobo$63bobo14bo9bo$22bo19bobo15bo7bo
15bobo$21bobo16bo5bo16bobo$3o17bo3bo17bobo$obo18bobo$3o19bo20bo20bo20b
o!

[muzik]

There's also some minor pixel bugs which are visible on greyed-out buttons on desktop - I can get pictures of it in action if desired.

Please do.

As promised:


(in these cases, the reverse button is affected by both, and the back and redo buttons in catagolue)

Again, these don't seem particularly consistent at all, so I'm not sure if it's fixable. It seems to be desktop-exclusive as well.

----

The "Alive" counter only seems to include state 1 cells from the none rule, shouldn't it be counting everything that isn't state 0?

Code: Select all

x = 16, y = 16, rule = none:P16,16
.ABCDEFGHIJKLMNO$PQRSTUVWXpApBpCpDpEpFpG$pHpIpJpKpLpMpNpOpPpQpRpSpTpU
pVpW$pXqAqBqCqDqEqFqGqHqIqJqKqLqMqNqO$qPqQqRqSqTqUqVqWqXrArBrCrDrErFrG
$rHrIrJrKrLrMrNrOrPrQrRrSrTrUrVrW$rXsAsBsCsDsEsFsGsHsIsJsKsLsMsNsO$sP
sQsRsSsTsUsVsWsXtAtBtCtDtEtFtG$tHtItJtKtLtMtNtOtPtQtRtStTtUtVtW$tXuAuB
uCuDuEuFuGuHuIuJuKuLuMuNuO$uPuQuRuSuTuUuVuWuXvAvBvCvDvEvFvG$vHvIvJvKvL
vMvNvOvPvQvRvSvTvUvVvW$vXwAwBwCwDwEwFwGwHwIwJwKwLwMwNwO$wPwQwRwSwTwUwV
wWwXxAxBxCxDxExFxG$xHxIxJxKxLxMxNxOxPxQxRxSxTxUxVxW$xXyAyByCyDyEyFyGyH
yIyJyKyLyMyNyO!

----

Would it be possible to add 180 degree rotation buttons, as well as diagonal flipping buttons, to the Select menu? Granted these operations can already be done by composing multiple other transformations, but shorthand is easier since you aren't forced to remember what combination is needed for each (and there may be situations where there's not enough room).

[rowett]

lemon41625's original notation (which I believe both CAViewer and lifelib use) simply takes a normal isotropic non-totalistic rulestring and appends /NFC or /NFE to the end for R2 Far Corners or R3 Far Edges respectively. I'm proposing that we use a modified HROT string instead since instead of being locked into range-1 Moore, range-2 Far Corners and range-3 Far Edges, we can instead specify arbitrary neighbourhoods so long as they fit our 8-cell restrictions, and as such all of these neighbourhoods (and more) become possible isotropic non-totalistic neighbourhoods

I presume a 6-cell expansion of isotropic non-totalistic hex rules would also be relevant.

[rowett]

Again, these don't seem particularly consistent at all, so I'm not sure if it's fixable. It seems to be desktop-exclusive as well.

From the screenshots there's nothing I can fix. Perhaps an updated graphics card driver or browser release will fix it.

The "Alive" counter only seems to include state 1 cells from the none rule, shouldn't it be counting everything that isn't state 0?

Fixed, thanks.

Would it be possible to add 180 degree rotation buttons, as well as diagonal flipping buttons, to the Select menu? Granted these operations can already be done by composing multiple other transformations, but shorthand is easier since you aren't forced to remember what combination is needed for each (and there may be situations where there's not enough room).

Not a priority for now. Also not sure I want to clutter the selection button area any more.

[muzik]

lemon41625's original notation (which I believe both CAViewer and lifelib use) simply takes a normal isotropic non-totalistic rulestring and appends /NFC or /NFE to the end for R2 Far Corners or R3 Far Edges respectively. I'm proposing that we use a modified HROT string instead since instead of being locked into range-1 Moore, range-2 Far Corners and range-3 Far Edges, we can instead specify arbitrary neighbourhoods so long as they fit our 8-cell restrictions, and as such all of these neighbourhoods (and more) become possible isotropic non-totalistic neighbourhoods

I presume a 6-cell expansion of isotropic non-totalistic hex rules would also be relevant.

If by that you mean these:

Code: Select all

x = 23, y = 7, rule = noneH
16bo2bo$7bobo$2o$obo4bo3bo4bo5bo$b2o$9bobo$19bo2bo!

then I suppose it'd make sense, especially to keep hexagonal HROT grids as functionally consistent with square grids as possible, athough I'm not sure if this specific case would actually yield any different behaviour from range-1.

The following "diagonal" expansion might allow for some different behaviour:

Code: Select all

x = 5, y = 5, rule = noneH
bo$o2bo2$bo2bo$3bo!

[muzik]

I should point out that I also invented a more compact notation for these, called "exploded Moore", about a year ago as well, which is more compact than modified HROT and is more in line with the traditional "Far INT" notation. This notation is the same as normal isotropic non-totalistic notation, except after the rulestring you append /FCxEy, where x is how far from the central cell the four corner cells are, and y is how far the four edge cells are.

Normal Moore is trivially /FC1E1. R2 Far Corners is /FC2E1:

Code: Select all

x = 5, y = 5, rule = LifeHistory
A3.E$2.AD$.A.A$2.A$A3.A!

R3 Far Edges is /FC1E3:

Code: Select all

x = 7, y = 7, rule = LifeHistory
3.E$3.D$2.ADA$A5.A$2.A.A2$3.A!

The trivial "double-skewed Moore" neighbourhood discussed earlier is /FC2E2:

Code: Select all

x = 7, y = 7, rule = LifeHistory
$.A.E.A$3.D$.A3.A$2.D$.E.A.A!

And this roughly circular neighbourhood is /FC2E3:

Code: Select all

x = 7, y = 7, rule = LifeHistory
3.A$.A.D.A$3.D$A5.A$2.D$.E3.A$3.A!

This would probably be a much easier notation to read than modified HROT in this case.