ConwayLife.com

rowett wrote:A note on LifeViewer memory usage:

Population graph data is now dynamically allocated.

rowett wrote:No. What I've done instead is remove the Theme slider in error cases since it makes no sense - test.

Makes sense - could Graph also be removed in this case (moving the Graph button to either the top middle or the bottom middle by default so that the menu remains symmetric even when it's not present)? It probably won't see much use in cases of unrunnable rules, so it'd probably be best removed in such cases.

Also: will the remaining rule families MCell can run ever be supported?

muzik wrote:Low priority, but will Mirek's Weighted Life notation for non-totalistic rules and Vote for Life notation for truly totalistic rules ever be supported?

Possibly. But if they do get supported it will be a while. There's a lot on the backlog.

muzik wrote:could Graph also be removed in this case

The Graph button gets disabled (greyed out) the same as if you'd used the [[ NOGRAPH ]] command.

Can we define as many history states as we want as long as the longevity and history states combined don't exceed 255? Also, something silly and probably not worth fixing:
There also appears to be a missing image on http://lazyslug.com/lifeview/plugin/viewer.html.

The graph button and theme bar also aren't deactivated with outright invalid RLE inputs on that page such as

muzik wrote:Can we define as many history states as we want as long as the longevity and history states combined don't exceed 255?

No because 2-state rules use states 128-255 for overlay (LifeHistory states etc.) and I don't want to extend it just for multi-state rules since that creates inconsistency.

muzik wrote:Also, something silly and probably not worth fixing:

Code: Select all

x = 2, y = 8, rule = B3/S23
bo$o$bo$bo$bo$bo$bo$bo!
[[ HISTORYSTATES 4294967359 ]]

I'll take a look.

muzik wrote:There also appears to be a missing image on https://lazyslug.com/lifeview/plugin/viewer.html

It's not missing. It gets created when you use hotkey "o" or Shift and "o" as the instructions say above it.

muzik wrote:The graph button and theme bar also aren't deactivated with outright invalid RLE inputs

Thanks, I'll take a look.

Can a button (or two, one for with the graph as well) be added inside the viewer that takes said screenshot, if not already? Otherwise it's not possible to take a screenshot in devices that don't have a keyboard at hand with the viewer.

------

Another random low-priority suggestion: LTL Star, Cross and Saltire neighbourhoods, for parity with Square Cell (see here). Of course, the "NC" proposed in said thread would conflict with the circular neighbourhood, so we'd have to come up with something a bit different if these were to be added (which is almost certaintly not too high of a priority anyway at the moment).

muzik wrote:Can a button (or two, one for with the graph as well) be added inside the viewer that takes said screenshot, if not already?

LifeViewer has two things it can do when you take a screenshot with hotkey "o" (or a graph screenshot with hotkey Shift and "o"):

1. If the page contains an <img id="screenshot"> tag it updates the image with the screenshot. This is one of the things the page is testing.
2. If not it attempts to open a new browser tab/window with a generated html page containing the screenshot image. Normally this fails due to popup blocking in the browser.

In either case it's not going to be helpful on tablets and phones since there's not much you can do with the image once generated.

On a PC you can right click on the image and choose "Save image as..." from the pop-up menu.

rowett wrote:Another random low-priority suggestion: LTL Star, Cross and Saltire neighbourhoods.

Highly unlikely at the moment. In general things get added when there is enough demand.

I'm pretty sure you can tap and hold and save image on Safari just as easily.

muzik wrote:I'm pretty sure you can tap and hold and save image on Safari just as easily.

True. However there are currently no web pages that use option 1 (above) apart from the test page, and option 2 doesn't work because of popup blockers.

On the topic of MCell rule formatting, can we get support for 1D rules with a range value (although with only R1 supported to begin with)?
However, MCell actually handles 1D rule integers as hexadecimal, instead of decimal, so the above rule (rule 54) would actually be rule 36 by Mirek's formatting:
Again, not the top priority, but still something to consider I suppose.

rowett wrote:

muzik wrote:I'm pretty sure you can tap and hold and save image on Safari just as easily.

True. However there are currently no web pages that use option 1 (above) apart from the test page, and option 2 doesn't work because of popup blockers.

Popup blockers (the Safari popup blocker, at least) will activate if the site attempts to open a new window, but don't when it just opens a new tab.

77topaz wrote:Popup blockers (the Safari popup blocker, at least) will activate if the site attempts to open a new window, but don't when it just opens a new tab.

Unfortunately this is both browser specific and in some cases based on user settings.

77topaz wrote:Something odd I just noticed: when you have a LtL pattern with history states, using the autofit option zooms to the entire envelope of the pattern including the history states, as opposed to just the pattern itself as it does for other rules.

This should now be fixed. Test case is here.

rowett wrote:This should now be fixed. Test case is here.

"AUTOFIT 2-state LtL Moore" has the very tip of the bug outside of the window for most of the time; is this intentional?

Also, on the new buttons: HistFit should be greyed out when AUTOFIT is off, and Major should be greyed out when the grid is off. (I'd also personally move the grid and autofit buttons into the settings page, since I feel they belong there better due to being on/off toggles and not being as immediately useful as the fit pattern button, and this would also allow the START/STOP and WAYPT/LOOP indicators to have squares of their own, but that's probably just me.)

(EDIT: Also, grey out Details when Timing isn't active)

muzik wrote:"AUTOFIT 2-state LtL Moore" has the very tip of the bug outside of the window for most of the time; is this intentional?

Not specifically. It's a function of the smoothing that the AutoFit algorithm uses and mostly causes the edge challenge you spotted at high zoom levels with a pattern that fills the display. I'll see if it's easy to adjust for that case.

muzik wrote:Also, on the new buttons: HistFit should be greyed out when AUTOFIT is off, and Major should be greyed out when the grid is off.

I thought about that but decided there's no reason to do so. It's just putting an artificial constraint on those settings. I might indeed want to toggle grid major before switching the grid lines on, or turn on History AutoFit mode before turning on AutoFit.

muzik wrote:I'd also personally move the grid and autofit buttons into the settings page, since I feel they belong there better due to being on/off toggles and not being as immediately useful as the fit pattern button

The buttons on the main menu are there because they're more commonly used (at least by me) than the ones hidden in the settings menu.

muzik wrote:"AUTOFIT 2-state LtL Moore" has the very tip of the bug outside of the window for most of the time; is this intentional?

Try this one.

rowett wrote:

muzik wrote:"AUTOFIT 2-state LtL Moore" has the very tip of the bug outside of the window for most of the time; is this intentional?

Try this one.

Definitely an improvement.

rowett wrote:

muzik wrote:Also, on the new buttons: HistFit should be greyed out when AUTOFIT is off, and Major should be greyed out when the grid is off.

I thought about that but decided there's no reason to do so. It's just putting an artificial constraint on those settings. I might indeed want to toggle grid major before switching the grid lines on, or turn on History AutoFit mode before turning on AutoFit.

I suppose one thing you could do is allow the major grid lines to be shown without the minor grid lines in such cases where they're not selected...

Can HISTORYSTATES be defined as part of a theme, so that different themes can have different amounts of history states defined for each of them (0 for 0 and 6, 1 for 8 and 9, and 63 for the rest)? Or would that not be possible due to it being processed at pattern load time?

Same for the presence of the grid, the colours of the grid and the major intervals of the grid; can these also be made to be defined through the theme? I want to propose new themes based on the default settings of Golly and MCell.

Names shown for each of the themes could be useful as well; for example, theme 10 would be the LifeHistory theme.

LtL 2-state von Neumann patterns now run faster. Test case is here. Scroll down to the final test.

muzik wrote:Can HISTORYSTATES be defined as part of a theme, so that different themes can have different amounts of history states defined for each of them (0 for 0 and 6, 1 for 8 and 9, and 63 for the rest)?

For the example you gave it's irrelevant since the colours mean you can't tell what the HISTORYSTATES setting is for those Themes.
But to answer your question, no it can't be defined as part of a Theme.

muzik wrote:Same for the presence of the grid, the colours of the grid and the major intervals of the grid; can these also be made to be defined through the theme? I want to propose new themes based on the default settings of Golly and MCell.

Yes they could be.

muzik wrote:Names shown for each of the themes could be useful as well; for example, theme 10 would be the LifeHistory theme.

Shown when you switch Themes?

rowett wrote:

muzik wrote:Names shown for each of the themes could be useful as well; for example, theme 10 would be the LifeHistory theme.

Shown when you switch Themes?

Yes, and preferably also in the slider and as a selectable name in code boxes.

rowett wrote:LtL 2-state von Neumann patterns now run faster. Test case is here. Scroll down to the final test.

I'm getting about 20 fps with 100% (usage, I can't remember exactly what that percentage stands for) for that one, compared to 60 fps with about 60% for the range-100 Moore bug and 9 fps for the range-500 Moore bug.

77topaz wrote:I'm getting about 20 fps with 100% (usage, I can't remember exactly what that percentage stands for) for that one, compared to 60 fps with about 60% for the range-100 Moore bug and 9 fps for the range-500 Moore bug.

The percentage figure is showing the workload i.e. what percentage of the budgeted update time was used. For smooth 60fps animation it needs to be less than 100%.

On my development machine I'm getting:

• Range 100 von Neumann Bug: 26fps / 100% load
• Range 100 Alien Bug (Moore): 60fps / 42% load
• Range 500 Alien Bug (Moore): 11fps / 100% load