Pattern viewer for forum threads

[rowett]

Looks like I've been giving you hell for just about a year now

Happy anniversary!

Will it ever be possible to draw using dead states of different ages (or, indeed, live states of different ages)? Only freshly created and never alive are available for usage.

Probably not since they only exist at runtime and aren't in the RLE (so you can't load or save them).

[rowett]

For me (I use Safari 9.1.3) the viewer will fail to render patterns whenever the edge or gridlines are in view.

I don't have a Mac so can't test this. Does anyone else with a Mac and that version of Safari see the same issue?

Also when you say "fail to render" what actually happens?

[77topaz]

I have a significantly newer version of Safari (12.1.2), and I don't see that issue. The only thing I see that might be related to the issue is that the holiday-snow accumulates on top of gridlines the same way it does on live cells.

[muzik]

It also seems to stay there when stopping and resetting the pattern, and carries over into new viewer windows as well

[rowett]

The only thing I see that might be related to the issue is that the holiday-snow accumulates on top of gridlines the same way it does on live cells.

It now ignores gridlines.

[rowett]

It also seems to stay there when stopping and resetting the pattern, and carries over into new viewer windows as well

It will now reset when the pattern resets and no longer carries over to new patterns in the same Viewer.

[muzik]

Also passes through objects when the viewing area is moved and when zooming the pattern, which causes weirdness.

[toroidalet]

I tried experimenting, and I'm not sure that it's actually the grid edge that's causing the first problem. Instead, when pixels below a certain height are visible, it stops rendering live (or visited) cells altogether. (interestingly, in the holiday theme the snow will fall as though there are no cells, so I think it's doing a lot more than just not rendering them).

The "critical value" appears to depend on the pattern (I think it's y=256*ceil(max(y)/256) (remember that the y axis is inverted; using positive y=up, it would be 256*floor(min(y)/256). I have not tried it with a rotated view.

The viewer's reaction to seeing gridlines (I'm pretty sure that's the problem there) is different but also interesting: it grays out the screen, except for a row of darker grey cells with only the major gridlines visible, and the lowest row of (gridded) cells. The major grid cells are consistent with the actual major gridlines, and the bottom row renders over them. (in the case that a major gridline directly overlaps with the bottom of the viewer, neither row will be rendered)

[rowett]

I tried experimenting, and I'm not sure that it's actually the grid edge that's causing the first problem.

Please will you post some screenshots.

[dbell]

The Pattern Viewer is really useful. Thanks to whoever developed it.

But there is a little problem that has been there for a long while running on firefox on Linux.

When single stepping a pattern, it doesn't always update on each step. I have to either single step again or move the cursor out of the window and back in again to see the step.

Does anyone else have this problem?

BCNU,
-dbell

[rowett]

When single stepping a pattern, it doesn't always update on each step. I have to either single step again or move the cursor out of the window and back in again to see the step.

I can't reproduce this problem. Please will you give me some more details:

• Which version of Linux are you using?
• Which version of Firefox?
• An example pattern where you see this issue
• Are you using the UI or the keyboard to single step?

[dbell]

Here is my system information:

Linux Mint 19 Cinnamon 64-bit
Firefox Quantum 61.0.1 64-bit
Mozilla Firefox for Linux Mint mint-1.0

The viewer shows the problem for any pattern I think. For example, from the Oscillator Discussion Thread, the recent post byIan07 about the simple two eaters object:

x = 9, y = 8, rule = B3/S23
2o$bo$bobo$2b2o$5b2o$5bobo$7bo$7b2o!

It only sometimes fails by using the GUI to hit the right arrow single step button without moving the mouse afterwards. But then any movement of the mouse after the button is pressed updates the pattern.

Hitting the space key single steps with no problems.

Maybe only my configuration shows the problem, but I don't know which component.

Anyway, now that I know about using the space key, the issue isn't as annoying as before.

Thanks for investigating it.

BCNU,
-dbell

[rowett]

Linux Mint 19 Cinnamon 64-bit
Firefox Quantum 61.0.1 64-bit
Mozilla Firefox for Linux Mint mint-1.0

Thanks for the details.

It only sometimes fails by using the GUI to hit the right arrow single step button without moving the mouse afterwards. But then any movement of the mouse after the button is pressed updates the pattern.

I've just uploaded Build 474 which may address the problem. Please hard refresh your browser and try again. If you click "Help" on LifeViewer (or press key "H") it will tell you which Build you're running.

[dbell]

Thanks for the update. It seems to work just fine now!

BCNU,
-dbell

[rowett]

Build 475 is now live on the Forums and LifeWiki

Please note: you will need to refresh your browser to use the new build (Ctrl-F5 on Chrome)

Enhancements since the last released build:

• improved @TABLE runtime and decode performance
• @TABLE and @TREE matches are now case-insensitive
• allow @RULE to be in pattern comments
• export build number
• prettier rendering at ZOOM > 1 (when ANGLE=0 and LAYERS=1)
• secret snow mode

Fixes since the last released build:

• increase update count for some browsers
• IE compatibility fixes
• fixed reading RuleTables with missing final new line
• reset pattern type flags before RuleTable decode
• fix quotes in comments for tokenizer
• allow empty @TREE or @TABLE sections
• fix pattern settings not being reset when rule already in cache
• fix an issue when Repository load fails
• list controls were not respecting custom background colour

The updated hotkey map detailing the LifeViewer keyboard controls is here.

Comments, feedback, suggestions and bug reports welcome!

[muzik]

Will snow be accessible at any time of the year and be toggleable as a scripting or menu option like stars are?

[rowett]

Will snow be accessible at any time of the year and be toggleable as a scripting or menu option like stars are?

It is accessible in a secret way. Your task, if you accept it, is to find out how.

[Gustone]

Why is all blurry now

[rowett]

Why is all blurry now

Because LifeViewer has a new renderer which removes aliasing effects. Please try Build 476 (hard refresh your browser and try again) which should make it less blurry.

[muzik]

New merge request with some rule aliases got accepted in, so these can be added to lifeviewer's alias list: https://gitlab.com/apgoucher/catagolue/ ... 049ce563b9

I've also done a bit of digging lately and unearthed a few rather old isotropic non-totalistic ruletables which don't seem to explicitly mention the actual rulestrings. Could you (or someone else) try figuring them out so they can be added to both catagolue and lifeviewer for completion's sake (and also so that lifeviewer doesn't have to take time loading the rule table instead of just using the alias and being instantly available)?

viewtopic.php?f=9&t=1480&p=26017#p26017
viewtopic.php?f=11&t=1971&p=26022#p26022
viewtopic.php?f=11&t=1972&p=26027#p26027
viewtopic.php?f=11&t=1973&p=26071#p26071
viewtopic.php?f=11&t=803&p=26147#p26114
viewtopic.php?f=11&t=803&p=26147#p26147
viewtopic.php?f=11&t=1468&p=26323#p26323
viewtopic.php?f=11&t=1971&p=26608#p26608

EDIT: Seem to have found a bug on that third link - open the first RLE on it and it appears at the bottom right instead of centered

[muzik]

...and it seems as though pages with multiple viewer windows aren't handled as well again, since this murders safari:

viewtopic.php?f=11&t=4098&p=84359&hilit ... ned#p84359


EDIT: it doesn't even seem to be an issue with just viewer windows.

[toroidalet]

Although the anti-aliasing is gone, the annoying slowness that occurs at zoom levels with more than 1 pixel/cell is still there.

I made a video showing rendering bugs, you can find it at https://www.youtube.com/watch?v=mpltWadncZg (the forums don't let you upload videos). It also includes a centering problem newly introduced in build 476 (autofit brings the view to the upper left corner instead of the center).

If you need more information, I'm happy to help.

[rowett]

Build 477 is now live on the Forums and LifeWiki

Please note: you will need to refresh your browser to use the new build (Ctrl-F5 on Chrome)

Enhancements since the last released build:

• new button Settings->Advanced->Render Quality (hotkey Ctrl+"Q") toggles rendering quality
  • high quality
    • cells are anti-aliased at ZOOM > 1
    • slower and uses more memory
  • standard quality (the original)
    • default rendering mode
    • faster and uses less memory
• new script command [[ QUALITY ]] enables high quality rendering
• added new aliases

The updated hotkey map detailing the LifeViewer keyboard controls is here.

Comments, feedback, suggestions and bug reports welcome!

[rowett]

New merge request with some rule aliases got accepted in, so these can be added to lifeviewer's alias list

Done, thanks.

I've also done a bit of digging lately and unearthed a few rather old isotropic non-totalistic ruletables which don't seem to explicitly mention the actual rulestrings. Could you (or someone else) try figuring them out

It won't be me but happy to add them if someone else does!

EDIT: Seem to have found a bug on that third link - open the first RLE on it and it appears at the bottom right instead of centered

I can't reproduce this.

[rowett]

...and it seems as though pages with multiple viewer windows aren't handled as well again

The high quality rendering mode uses more memory. The default is now standard rendering.