ConwayLife.com

dvgrn wrote:Why the apparent discrepancy between universe size horizontally and vertically, by the way?

dvgrn wrote:This one, from the Cool Rules with One Known Glider thread, behaves a bit strangely -- crashes into something, but then it seems like the something must not be the edge of the universe after all.

• growing the grid was not being triggered early enough at high STEP sizes

• A in edge test 1
• B in edge test 2
• Fail in edge test 3

• smooth camera transitions:
  • between POIs (hotkey "j")
  • when restoring saved View (hotkey "v")
  • when using Fit Zoom (hotkey "f")
  • when setting Zoom to a multiple (hotkeys "1", "2", "3", "4", "6" and "8")
• saved View and POIs now also remember ANGLE
• further performance improvements to rendering when ANGLE=0 and clipping
• better handling of patterns hitting the grid boundary for non-explosive rules

• Fit Zoom and AutoFit controls now disabled during waypoint playback
• [[ X ]] and [[ Y ]] script commands now allow arguments between +/- half maximum grid size, rather than half current grid size

• much faster rendering
• display coordinates of cell under mouse cursor
• unlimited step back
• ability to define Points Of Interest on the grid
• maximum grid boundary now drawn in grey with improved spaceship killing

1. ALIVE
2. DEAD
3. MARK1
4. MARKALIVE
5. MARK2
6. KILL

rowett wrote:Is there a canonical set of names for the states which I can use in the [[ COLOR ]] script command? For example (and to comply a little with the existing command):

1. ALIVE
2. DEAD
3. MARK1
4. MARKALIVE
5. MARK2
6. KILL

state 0:  OFF
state 1:  ON
state 2:  history/envelope (state=2 if cell was ever ON)
state 3:  marked ON (may change to OFF but will always remain marked)
state 4:  marked OFF (may change to ON but will always remain marked)
state 5:  start ON (becomes a normal marked OFF cell when it dies)
state 6:  boundary OFF

dvgrn wrote:MARKALIVE or MARK1ALIVE or MARK1ON, or just MARK1, would be the right name for State 3, rather than State 4 as you seem to have it in your list. All even numbered states can be thought of as OFF states -- this is a carry-over from an old Mirek's Cellebration convention. Then I guess you'd need State 4 = MARK1OFF and State 5 = MARK2 just as you have it, or MARK2ALIVE if you want.

dvgrn wrote:"DEAD" or "OFF" seems to me to apply more to State 0 than for State 2 (HISTORY? WASALIVE?).

State 0: BACKGROUND | OFF
State 1: ALIVE | ON
State 2: DEAD | HISTORY
State 3: MARK1
State 4: MARK1OFF
State 5: MARK2
State 6: KILL or perhaps BOUNDARY?

rowett wrote:So my proposal is now:

Code: Select all

State 0: BACKGROUND | OFF
State 1: ALIVE | ON
State 2: DEAD | HISTORY
State 3: MARK1
State 4: MARK1OFF
State 5: MARK2
State 6: KILL or perhaps BOUNDARY?

Note it will continue to support "ALIVERAMP" and "DEADRAMP" also. How does that sound?

dvgrn wrote:It's a little odd that there's a MARK1OFF but no MARK2OFF, but that's just the way it is.

• integration with Molly
  • add a "Show in Molly" link to patterns posted on the ConwayLife.com forum that are too big or use a rule that LifeViewer can not execute
• switched around the Layers, Depth and Theme controls to better match hotkey positions
• layers now use ZOOM to determine level of detail for rendering
• [R]History state 6 execution is now tile-based and much faster
  • added number of state 6 tiles to help information
• better [R]History ZOOM < 1 rendering with state reordering

• some invalid [R]History style rules were being marked as valid LifeHistory
• fixed potential issue with initial grid size ignoring maximum STEP size

rowett wrote:All yours for testing, Dave!

dvgrn wrote: Build 169 looks really good so far. @Nathaniel, I've done enough testing that it seems okay to release it, with the usual possibility of rolling back if forum-dwellers start to report problems from some thread that I haven't checked yet. I'll try to find time to run some more complete tests over the next few days.

dvgrn wrote: However, I've recently started a new full-time QA job here in Madison

dvgrn wrote: -- Drat, I still have to get an [R]History rule-making script done, too. That should be an interesting little coding project, hopefully not too painful.

• patterns can be placed at an offset from the centre of the grid
  • [[ XOFFSET <number> ]] to set x offset
  • [[ YOFFSET <number> ]] to set y offset
• added ability to create custom [R]History state colours with [[ COLOR <statename> R G B ]]
  • <statename> must be "OFF", "ON", "HISTORY", "MARK1", "MARKOFF", "MARK2" or "KILL"
  • added state names to [R]History colours in help information
• added [[ COLOR BOUNDARY R G B ]] to set custom boundary colour around the grid (at 8192x8192 size)
  • default is the [R]History "KILL" grey
• modest performance improvements to boundary clear

• hotkey ZOOM changes were resetting ANGLE to 0
• fixed an issue with the RLE pattern decoder which would ignore invalid characters in rule names

rowett wrote:Build 170 is available on the lazyslug server

dvgrn wrote:... and the forbidden zone is offset significantly to the left of the visible edge -- 16 cells. The opposite offset shows up on the left side, but the bottom boundary again matches the visible edge exactly.

All very minor and cosmetic, and doesn't really justify a new build all by itself, but maybe something to put on the backlog.

1. Computes the next generation of cells on the grid which is a set of bits
2. Updates the colour grid which is a set of 256 pen colours stored as bytes and is used to add the history
3. Projects and renders the colour grid onto an in-memory Canvas converting the pens to RGBA values stored as 32bit unsigned integers

1. I'm planning some work on changing the memory order representation of the grid and colour grid to keep each tile as a consecutive series of bytes. This will be more friendly to the processor cache so it's possible I'll get some speed up. The changes to the algorithms to reflect this will also remove the need for the optimization above. The hope is that this work will speed up tasks 1 and 2 above.
2. I've been playing a little bit with WebGL which should accelerate the projection and rendering of the colour grid onto the Canvas. However I've got some learning to do and I'm not yet sure how easy it will be to implement the adaptive sub-sampling I use at ZOOMs < 1 to ensure significant cells are always displayed. This work should speed up task 3 above. However, I'll need to ensure compatibility with older hardware and browsers that may not support WebGL.

rowett wrote:Nathaniel - please will you release this build on the forum. Thanks!

Nathaniel wrote:

rowett wrote:Nathaniel - please will you release this build on the forum. Thanks!

Done! Sorry for the delay.

• only clear boundaries if pattern is near the edge of the grid
• clicking step back on a running pattern now functions identically to the pause button (i.e. looping is cancelled if defined)

• validate that patterns still fit on the grid when XOFFSET or YOFFSET script commands specified
• left and right boundaries are no longer 16 pixels from the edge

• drawing starfield is now 25% faster in the general case and 4x faster at ANGLE=0
• drawing gridlines is now 3.5x faster

• spaceships that hit the boundary are now instantly deleted in their entirety

rowett wrote:Dave, let me know if you prefer this behaviour to the previous boundary function.

x = 53, y = 37, rule = B3/S23
48b3o$48bobo3$2bo$bobo$o3bo43bobo$o3bo43b3o$bobo$2bo15bobo$17bo2bo$18b
o10bo19b3o$30b2ob3o12bob3o$29bo6bo11b2ob2o$22b2o5bo7bo3b7o$b3o18b2o6bo
4bobo3b2o$bo19bo2bo9bo8bo2bo$2b2o5b2o3b2o5bobo6b2o2bo10b2o$2bo2b2o2b2o
3b2o2b3o2bo5b2o3bo10bo2b2o$3b3o12bo2b2o6bo2b2o12b3o$4bo14b3o8b3o3b2o3b
2o4bo$20bo10bo4b2o3b2o2$9b2o3b2o17bo11bo$9bo5bo17bo11bo2$5b2o11b2o$5b
2o2b2o3b2o2b2o16bo5bo$35b3o3b3o$8bo2bobo2bo15bobo3bobo3bobo$7bo9bo13bo
2b2o2bobo2b2o2bo$6bobob2ob2obobo13bo3b2o3b2o3bo$5b2o3b2ob2o3b2o$6bo2bo
5bo2bo$6b2o2bo3bo2b2o14bo2b2o3b2o2bo$7b3o5b3o16b3o5b3o$8bo7bo18bo7bo!
#C [[ THEME 0 GRID YOFFSET 4000 Y -4000 ZOOM 1.7 STEP 10 ]]

dvgrn wrote:Nobody expects a multi-part spaceship like a Cordership to be well-behaved at a boundary (I tried them; they're not...)

• script command [[ DELETERANGE <1..16> ]] defines how near live cells have to be to each other to be deleted as part of a group (default is 3)

rowett wrote:LifeViewer would simply need to be supplied with a 512 bit value containing 4' values for each input. This could simply be encoded into a 128 character hex string, or even an 86 character base64 encoded string.
I could then add a script command [[ RULE <hex string>> ]].

Thoughts?

dvgrn wrote:

rowett wrote:LifeViewer would simply need to be supplied with a 512 bit value containing 4' values for each input. This could simply be encoded into a 128 character hex string, or even an 86 character base64 encoded string.
I could then add a script command [[ RULE <hex string> ]].

Thoughts?

Sounds reasonable to me. That allows support for von Neumann neighborhoods as a small subset, and also any of the non-totalistic rules with rotate4reflect symmetry that have been getting explored recently

-- So what got you thinking along these lines? Was it the recent discussion that came up recently on the apgsearch thread, about Alan Hensel's non-totalistic rule format?

dvgrn wrote:It should be fairly straightforward to write a utility to convert Hensel's rule notation into a 512-bit value... which I suppose means that it might be possible for LifeViewer to support Hensel's notation directly, once extended rule support is available anyway...?

dvgrn wrote:Will all these new transition possibilities make LifeViewer run any slower for these rules? Or isn't there any rule-specific trickery involved in the evolution algorithm?