Pattern viewer for forum threads

[rowett]

For some reason - the white doesn't leave red trace now (only the yellow).

Actually it never did. But it does now!

Also fixed the Fit Zoom and added drawing of the gray cells (but beware these don't behave like real LifeHistory gray cells).

See here for the updated prototype.

Please let me know if this is now working as expected.

Now working on the Zoom < 1 requirement.

[rowett]

As I mentioned the only thing that "missing" (we just can't see it in that test mode) - is that patterns with LifeHistory rule will automatically load with this theme in the external viewer (as after the show in viewer option was added we all started to be much lazier with the viewer in the messages themselves).

Yes, they do.

[simsim314]

Yes, they do.

Great then! Working well now as far as I can tell.

Now working on the Zoom < 1 requirement.

This is obviously your decision - but I would suggest to make a new release. All those changes are very welcomed in the viewer, and will make our lives so much easier and user-friendly. Zoom < 1 is absolutely optional, meanwhile we're still using the old viewer (and copying LifeHistory patterns into golly).

[rowett]

Now working on the Zoom < 1 requirement.

This is obviously your decision - but I would suggest to make a new release. All those changes are very welcomed in the viewer, and will make our lives so much easier and user-friendly. Zoom < 1 is absolutely optional, meanwhile we're still using the old viewer (and copying LifeHistory patterns into golly).

Zoom < 1 now (mostly) working in this version of the prototype.

At T=0 all works perfectly. At T>0 I don't properly blend the overlay with the grid so, for example, if you run "LifeHistory overlay test 1" (the bottom 1) to T=100 and zoom out below 1x you'll see some green dots in the middle of the X which are from the initial position. Fixing this would be computationally expensive and I think it's probably good enough as is. Thoughts?

[simsim314]

In my opinion active cells that are disappearing is strange behavior. If I were to implement zoom out I would make histogram of all cells in that pixel, and draw the most dominant one between the actives, and if no actives exist the most dominant of the non-active . Meaning if there are few active cells (say 4 greens and 2 yellows and 10 black), I would take the color of the most dominant active (i.e. green), if there is non active only (say 6 blues and 10 reds) - I would take the color the most dominant non-active cells (i.e. red).

EDIT Thinking of it I would consider to ignore the black ones from the histogram. If there is some color in that pixel which is not black, I would prefer to see it instead of black, even if black is the most dominant.

[dvgrn]

At T=0 all works perfectly. At T>0 I don't properly blend the overlay with the grid so, for example, if you run "LifeHistory overlay test 1" (the bottom 1) to T=100 and zoom out below 1x you'll see some green dots in the middle of the X which are from the initial position. Fixing this would be computationally expensive and I think it's probably good enough as is. Thoughts?

Hmm, I don't know how to suggest to solve the computational expense problem, and I agree with simsim314 that a version somewhere around this point is definitely worth releasing.

However, I also agree that ON cells should ideally be preferred over OFF cells. The current behavior will be a little bit strange in some cases.

For example, try zooming out on "LifeHistory overlay test 2" to below 1x, then running the pattern. The white and yellow cells remain visible, and no activity can be seen until the active cells get out from under their blue umbrella, so to speak.

Can this be improved at all by changing the draw order -- i.e., by drawing any extra LifeHistory states first, and then drawing the regular LifeViewer layer on top of that?

[rowett]

In my opinion active cells that are disappearing is strange behavior. If I were to implement zoom out I would make histogram of all cells in that pixel, and draw the most dominant one between the actives, and if no actives exist the most dominant of the non-active . Meaning if there are few active cells (say 4 greens and 2 yellows and 10 black), I would take the color of the most dominant active (i.e. green), if there is non active only (say 6 blues and 10 reds) - I would take the color the most dominant non-active cells (i.e. red).

EDIT Thinking of it I would consider to ignore the black ones from the histogram. If there is some color in that pixel which is not black, I would prefer to see it instead of black, even if black is the most dominant.

Yes it mostly works as you suggest other than:

• it uses an optimization to avoid having to compute histograms because they're expensive to compute per display pixel
• it has to cope not just with 6 states but also with 64 shades of states 0 and 1
• i'm not actually running a 6 state model, i'm running a 2-state model and using a colour overlay with some simple rules to partially emulate LifeHistory

Having said all that it's fairly easy to fix. I'm just working on how to make it perform.

[simsim314]

To simplify things I would suggest to ignore the LifeHistory colors at scale < 1 (and even the shades). People use scale < 1 to roughly estimate what is going on - so they generally need to see the active cells (and maybe blue cells). They don't want to see stuff in details - only rough approximation of what is going in in large picture.

For this reason I would suggest to make simpler "histogram" - if there is something ON draw active (green), otherwise don't draw anything (black). Just like golly does with maybe extra for the blue. Meaning - just do to LifeHistory whatever you're doing to any other rule, and ignore the special states, they simply less relevant at high scale.

I think that scale < 1 is complex enough problem that wasn't solved in golly exactly because of it's computational cost, so I don't really miss this functionality so much in the viewer - I usually run patterns in high scales, and when the pattern is too big - I use golly anyway, because what can you do - javascript is not C. I don't expect the caterpillar to run in the viewer. The viewer is for 99% of the small patterns that people post in the forum.

[dvgrn]

To simplify things I would suggest to ignore the LifeHistory colors at scale < 1 (and even the shades). People use scale < 1 to roughly estimate what is going on - so they generally need to see the active cells (and maybe blue cells). They don't want to see stuff in details - only rough approximation of what is going in in large picture.

The exception is labels, which are usually state 4 -- and it's really quite nice to be able to see them at all scales, as in the current Build 159. See the first pattern on the latest test page.

It seems possible that the T=0 state could be used as a background rather than an overlay at low scales. (?) It definitely seems good to be able to see the same active cells that can normally be seen for a standard low-scale Life pattern. Labels and other marked-OFF cells will mostly be seen in non-active areas of the grid -- if a red, white or yellow color is obscured by active cells at scale < 1x, that doesn't seem as important as the problem where LifeHistory blue cells (or other states) obscure the view of the current pattern state.

[rowett]

Having said all that it's fairly easy to fix. I'm just working on how to make it perform.

I believe it's all working now please check this one.

[simsim314]

I believe it's all working now please check this one.

Wow! It's now looking better than golly when zooming out!

[dvgrn]

I believe it's all working now please check this one.

Wow! It's now looking better than golly when zooming out!

Indeed it is -- not that that's terribly difficult, unfortunately. Maybe it's time for a checkbox in Golly preferences to sacrifice some drawing speed to get better-looking low-scale zooms.

Is Molly going to have reasonably efficient bounded-grid support, by the way?

Or maybe it's worth starting to think about a new HashLife+ algo that can handle subpixel zooms, calculating and storing a color along with each hash tile, according to some user-adjustable formula.

Since that will require horrible bug-wrestling anyway, maybe it will be worth tackling the problem of bounded grids at the same time -- set up the HashLife+ algorithm so that it actually supports bounded grids instead of just barely tolerating them.

I'd be very curious to see if it's possible to define hash tiles of various sizes that are missing various subsets of rows and/or columns. For example, the first several hashtiles might be normal, but the 1024x1024 hashtile might be missing one row and one column, to allow for efficient simulation of (let's say) 1023x1023 metapixels.

I'm not at all clear how much efficiency would be lost with this kind of adapted HashLife+ algorithm, but it seems as if both pieces of new functionality would require connecting hashtiles edge-to-edge in ways that are currently nonstandard.

Anyway, this is all probably a topic for a different thread... anyone care to start one?

[simsim314]

I think there is a thread on Golly scale down methodology.

Continue the issue a bit more...I would suggest to add to Rule format, scale down states hierarchy as well thus avoiding some external configurations except the rule itself. For starters each state could be ON state and OF state, or for more general purpose we can use - state priority. So two states with same priority compete by popularity, and states with different priorities win by comparing their priorities.

[rowett]

Build 160 is now live on conwaylife.com

Enhancements since the last released build:

• LifeHistory patterns can now be executed with all states displayed
  • state 6 is displayed but execution support will be in the next build
  • patterns can be zoomed out to 0.25x with full colour support
• added a "step back" button to the UI
  • step back hotkey "b" will pause execution if running
  • pause button image becomes "step forward" when paused
• added a "help" button to the UI
  • LifeViewer build number now at the top of the help text

Fixes since the last released build:

• failed to read pattern rules where one of the B/S sections was empty
• patterns could restart not from the start after more than one pattern run in the standalone viewer
• opening a pattern in the standalone viewer would not reset the stars mode
• fixed overflow in mouse wheel zoom which was causing a minor jump at zoom extremities

Here is a LifeHistory pattern using the new execution support:

Code: Select all

x = 140, y = 83, rule = LifeHistory
45.2D3.2D41.2D3.2D$44.D2.D.D2.D39.D2.D.D2.D$46.D2.D2.D35.3D3.D2.D2.D$
45.D3.D2.D40.D3.D2.D$44.4D2.2D40.4D2.2D2$40.D3.2D53.D3.2D$39.2D2.D2.D
9.3A23.3A13.2D2.D2.D$3D.6D.3D26.D2.D2.D9.A3B21.3BA9.3D2.D2.D2.D21.3D.
9D$.2D2.D2.D3.D27.D2.D2.D10.A2BA19.A2BA15.D2.D2.D22.2D2.D2.D3.D$.2D2.
D2.D3.D26.3D2.2D12.4B17.4B15.3D2.2D23.2D2.D2.D.D$.D.D.D2.D.D.D46.A2BA
15.A2BA46.D.D.D2.3D$.D.D.D2.D.D.D25.2D11.3A6.4B13.4B6.3A11.2D25.D.D.D
2.D.D$.D.D.D2.D.D.D24.D2.D10.A3B6.A2BA11.A2BA6.3BA10.D2.D24.D.D.D2.D$
.D2.2D2.D.D.D24.D2.D11.A2BA6.4B9.4B6.A2BA11.D2.D24.D2.2D2.D3.D$3D.2D
3.D.D25.D2.D12.4B6.A2BA7.A2BA6.4B12.D2.D23.3D.2D.6D$38.2D14.A2BA6.4B
5.4B6.A2BA14.2D$46.3A6.4B6.A2BA3.A2BA6.4B6.3A$28.D3.2D12.A3B6.A2BA6.
3B2.4B6.A2BA6.3BA12.D3.2D$27.2D2.D2.D12.A2BA6.4B6.AB3.BA6.4B6.A2BA12.
2D2.D2.D$23.3D2.D2.D2.D13.4B6.A2BA17.A2BA6.4B14.D2.D2.D$28.D2.D2.D14.
A2BA6.4B15.4B6.A2BA15.D2.D2.D$27.3D2.2D7.3A6.4B6.A2BA13.A2BA6.4B6.3A
6.3D2.2D$41.A3B6.A2BA6.4B11.4B6.A2BA6.3BA$21.2D3.2D14.A2BA6.4B6.AB13.
BA6.4B6.A2BA14.2D3.2D$20.D2.D.D2.D14.4B6.A2BA27.A2BA6.4B14.D2.D.D2.D$
16.3D3.D2.D2.D15.A2BA6.4B25.4B6.A2BA17.D2.D2.D$21.D3.D2.D7.3A6.4B6.A
2BA23.A2BA6.4B6.3A8.D3.D2.D$20.4D2.2D8.A3B6.A2BA6.4B21.4B6.A2BA6.3BA
7.4D2.2D$37.A2BA6.4B6.A2BA19.A2BA6.4B6.A2BA$38.4B6.A2BA6.4B17.4B6.A2B
A6.4B$39.A2BA6.4B6.A2BA15.A2BA6.4B6.A2BA$40.4B6.A2BA6.4B13.4B6.A2BA6.
4B$41.A2BA6.4B6.A2BA11.A2BA6.4B6.A2BA$42.4B6.AB8.4B9.4B8.BA6.4B$43.A
2BA16.A2BA7.A2BA16.A2BA$44.4B16.4B5.4B16.4B$45.A2BA16.AB7.BA16.A2BA$
46.4B41.4B$47.AB43.BA$69.3D20.B$70.CD$69.3D$47.AB43.BA$46.4B41.4B$45.
A2BA16.AB7.BA16.A2BA$44.4B16.4B5.4B16.4B$43.A2BA16.A2BA7.A2BA16.A2BA$
42.4B6.AB8.4B9.4B8.BA6.4B$41.A2BA6.4B6.A2BA11.A2BA6.4B6.A2BA$40.4B6.A
2BA6.4B13.4B6.A2BA6.4B$39.A2BA6.4B6.A2BA15.A2BA6.4B6.A2BA$38.4B6.A2BA
6.4B17.4B6.A2BA6.4B$37.A2BA6.4B6.A2BA19.A2BA6.4B6.A2BA$21.2D3.2D8.A3B
6.A2BA6.4B21.4B6.A2BA6.3BA8.2D3.2D$20.D2.D.D2.D7.3A6.4B6.A2BA23.A2BA
6.4B6.3A7.D2.D.D2.D$16.3D3.D2.D2.D15.A2BA6.4B25.4B6.A2BA17.D2.D2.D$
21.D3.D2.D14.4B6.A2BA27.A2BA6.4B15.D3.D2.D$20.4D2.2D14.A2BA6.4B6.AB
13.BA6.4B6.A2BA13.4D2.2D$41.A3B6.A2BA6.4B11.4B6.A2BA6.3BA$28.D3.2D7.
3A6.4B6.A2BA13.A2BA6.4B6.3A7.D3.2D$27.2D2.D2.D14.A2BA6.4B15.4B6.A2BA
14.2D2.D2.D$23.3D2.D2.D2.D13.4B6.A2BA17.A2BA6.4B14.D2.D2.D$28.D2.D2.D
12.A2BA6.4B6.AB3.BA6.4B6.A2BA13.D2.D2.D$27.3D2.2D12.A3B6.A2BA6.4B.4B
6.A2BA6.3BA11.3D2.2D$46.3A6.4B6.A2BA3.A2BA6.4B6.3A$38.2D14.A2BA6.4B5.
4B6.A2BA14.2D$2.4D.3D.3D23.D2.D12.4B6.A2BA7.A2BA6.4B12.D2.D25.4D.6D$.
D3.D2.D3.D24.D2.D11.A2BA6.4B9.4B6.A2BA11.D2.D24.D3.D2.D3.D$.D6.D3.D
24.D2.D10.A3B6.A2BA11.A2BA6.3BA10.D2.D24.D6.D.D$2.3D3.D.D.D25.2D11.3A
6.4B13.4B6.3A11.2D26.3D3.3D$5.D2.D.D.D46.A2BA15.A2BA50.D2.D.D$5.D2.D.
D.D27.D3.2D12.4B17.4B16.D3.2D27.D2.D$.D3.D2.D.D.D26.2D2.D2.D10.A2BA
19.A2BA14.2D2.D2.D22.D3.D2.D3.D$.4D4.D.D28.D2.D2.D9.A3B21.3BA9.3D2.D
2.D2.D22.4D2.6D$40.D2.D2.D9.3A23.3A14.D2.D2.D$39.3D2.2D52.3D2.2D2$45.
2D3.2D41.2D3.2D$44.D2.D.D2.D39.D2.D.D2.D$46.D2.D2.D35.3D3.D2.D2.D$45.
D3.D2.D40.D3.D2.D$44.4D2.2D40.4D2.2D

Comments, feedback, suggestions and bug reports welcome!

[simsim314]

[M. I. Wright]

Ooh, that's awesome - thanks a ton!

Just four minor things:

Code: Select all

#C generations rules are played ignoring extra states and with B/S flipped
x = 13, y = 5, rule = 12/34/3
ABA.AB.BA.ABA$.A2.B2.A3.A$.B2.AB.BA2.B$.A2.B3.B2.A$.B2.AB.BA2.B!

Code: Select all

#C B/S format is assumed
x = 13, y = 5, rule = 23/3
3ob2ob2ob3o$bo2bo2bo3bo$bo2b2ob2o2bo$bo2bo3bo2bo$bo2b2ob2o2bo!

Code: Select all

#C I think this should be accounted for as well
x = 13, y = 5, rule = life
3ob2ob2ob3o$bo2bo2bo3bo$bo2b2ob2o2bo$bo2bo3bo2bo$bo2b2ob2o2bo!

Code: Select all

#C your call - I've only seen one user posting RLEs in this format, so it's probably not worth handling
x = 13, y = 5, rule = Life
3A.2A.2A.3A$.A2.A2.A3.A$.A2.2A.2A2.A$.A2.A3.A2.A$.A2.2A.2A2.A!

[rowett]

Just four minor things

Many thanks for the bug report. I've fixed the first three and they will be in the next released build. I haven't decided on the fourth yet.

[gmc_nxtman]

Have a look at this post. I couldn't immeditately detect anything wrong with the rle, and it's hard to explain the bug.

[dvgrn]

Have a look at this post. I couldn't immeditately detect anything wrong with the rle, and it's hard to explain the bug.

The only problem is that LifeHistory doesn't have a state #7 ("G" in the RLE text). Golly refuses to run the pattern at all, but the LifeViewer just displays state-7 cells using black as the default color, because there isn't a color assigned for that state. Then for some reason, at T=1 it automatically converts state-7-or-higher cells to state-1 cells.

Probably the viewer should really be doing the state-7 to state-1 conversion at T=0, instead of T=1. On the other hand, it might make more sense for it to refuse to display or run anything at all, if it finds state=7 cells in LifeHistory. That pattern couldn't have been copied out of Golly, unless the LifeHistory rule had been previously modified to a non-standard form with extra states. Maybe the copy was done from a different-named rule, and then the rule name in the header was changed manually. (?)

[rowett]

Have a look at this post. I couldn't immeditately detect anything wrong with the rle, and it's hard to explain the bug.

The only problem is that LifeHistory doesn't have a state #7 ("G" in the RLE text). Golly refuses to run the pattern at all, but the LifeViewer just displays state-7 cells using black as the default color, because there isn't a color assigned for that state. Then for some reason, at T=1 it automatically converts state-7-or-higher cells to state-1 cells.

Probably the viewer should really be doing the state-7 to state-1 conversion at T=0, instead of T=1. On the other hand, it might make more sense for it to refuse to display or run anything at all, if it finds state=7 cells in LifeHistory.

LifeViewer is doing the conversion when it loads the pattern. At T=0 it draws all states as defined in the pattern (with state 7 in black as Dave said). From T=1 onwards it's drawing collapsed states (for execution) overlayed with states 3-6.
The correct answer is for LifeViewer to refuse to run this (as Golly) since it's an invalid LifeHistory pattern. This will be fixed for the next released build.

On an entirely unrelated note: Was there Life at T<0?

[Gustavo6046]

Just a sidenote. LifeHistory is becoming popular now!

[Alexey_Nigin]

For some reason LifeViewer tries to open this code box.

[rowett]

For some reason LifeViewer tries to open this code box.

Thanks for reporting it Alexey. It will be fixed in the next released build.

[gmc_nxtman]

For some reason, the bug with rules like (125/36) running with birth and survival rules reversed is not fixed.

[rowett]

For some reason, the bug with rules like (125/36) running with birth and survival rules reversed is not fixed.

I'm fairly sure it's fixed. Try refreshing the browser to ensure the new build (163) is loaded (you can check by clicking on the ? button at the top right of the LifeViewer).
If it's still not working please post an example pattern in this thread.