Life tag testing

[rowett]

Two hundred builds!

Not bad for a project that I started in the summer of 2012 as a vehicle to learn Javascript and HTML5.

[dvgrn]

Build 200 is now available on the lazyslug server...
Note: you no longer need to specify HEIGHT or ZOOM for the Wiki thumbnails.

Haven't tried this yet: if you do specify the ZOOM, does anything change, or does the auto-fitting override a ZOOM setting?

This case got me wondering this morning. It would be nice to be able to hard-code a zoom, or maybe a starting camera location, instead of relying on AUTOFIT -- just because the starting phase of the ship is so off-balance that it ends up wandering off the default view a lot of the time.

Another workaround would be to choose a different starting phase for the spaceship, of course, but that might not be a good option in some cases.

Two hundred builds!

Not bad for a project that I started in the summer of 2012 as a vehicle to learn Javascript and HTML5.

It's quite a milestone. If you haven't learned Javascript and HTML5 at this point, you're giving an awfully good imitation of it.

[rowett]

Haven't tried this yet: if you do specify the ZOOM, does anything change, or does the auto-fitting override a ZOOM setting?

ZOOM is simply overridden by AutoFit so it's redundant.

This case got me wondering this morning. It would be nice to be able to hard-code a zoom, or maybe a starting camera location, instead of relying on AUTOFIT -- just because the starting phase of the ship is so off-balance that it ends up wandering off the default view a lot of the time.

Yes I have another of those where the starting shape of the pattern changes significantly enough during its cycle to mean the camera is not optimally placed. There are several potential solutions (e.g. reducing the AutoFit ZOOM factor slightly, making the AutoFit ZOOM factor configurable, allowing specification of a bounding box adjustment, etc.) but I haven't come up with an elegant one yet. Open to creative solutions!

[dvgrn]

Yes I have another of those where the starting shape of the pattern changes significantly enough during its cycle to mean the camera is not optimally placed. There are several potential solutions (e.g. reducing the AutoFit ZOOM factor slightly, making the AutoFit ZOOM factor configurable, allowing specification of a bounding box adjustment, etc.) but I haven't come up with an elegant one yet. Open to creative solutions!

The one I thought of is to have a ZOOM script setting override AUTOFIT, instead of the other way around -- but that's a fairly big change in behavior. It would work in this particular case, on the Wiki -- because people would naturally pick a ZOOM setting only when they didn't like the one the got from AUTOFIT.

But now I've forgotten what the original reasons were for ignoring ZOOM if AUTOFIT was specified. Seems like it made sense when the zoom level was going to be recalculated at every generation anyway -- but TRACK and TRACKLOOP are trying to smooth that out, so they effectively only set an initial view and then move it... so at least in those specific cases it would be good to allow script settings to control that initial view as much as possible.

[Nathaniel]

Build 200 is now available on the lazyslug server

This build should fix the recent ZOOM issue on the Wiki - please upload to the Wiki!

200 is now live on the forums and the wiki. Thanks!

[dvgrn]

Build 200 is now available on the lazyslug server

This build should fix the recent ZOOM issue on the Wiki - please upload to the Wiki!

200 is now live on the forums and the wiki. Thanks!

Wow, that certainly does turn all existing waypoint scripts on the forums into, mostly, frenetic zooms into the middle of nowhere.

I've fixed my most recent one and my first one, just as a start. Negating all the X and Y values isn't really all that time-consuming -- and luckily waypoint animations haven't really caught on all that much yet.

We'll see if the LifeViewer's recent escape onto the LifeWiki and the wider Internet changes that eventually...!

EDIT: This one is giving me some trouble. What am I forgetting?

Code: Select all

x = 914, y = 945, rule = B3/S23
2o$2o4$3o$o$bo28$41b3o$41bo$42bo28$37b3o$37bo$38bo28$78b3o$78bo$79bo
28$74b3o$74bo$75bo28$115b3o$115bo$116bo28$132b3o$132bo$133bo3$193b3o$
193bo$194bo28$176b3o$176bo$177bo8$229b3o$229bo$230bo28$219b3o$219bo$
220bo8$271b3o$271bo$272bo28$244b2o$243b2o$245bo8$304b3o$304bo$305bo28$
304b2o$303b2o$305bo8$355b2o$354b2o$356bo28$354b2o$353b2o$355bo18$394b
3o$394bo$395bo28$402b3o$402bo$403bo28$440b3o$440bo$441bo28$471b3o$471b
o$472bo28$517b3o$517bo$518bo28$505b3o$505bo$506bo8$564b3o$564bo$565bo
28$545b3o$545bo$546bo8$603b2o$602b2o$604bo28$600b3o$600bo$601bo8$647b
3o$647bo$648bo28$625b3o$625bo$626bo8$673b2o$672b2o$674bo28$672b2o$671b
2o$673bo8$716b2o$715b2o$717bo28$705b2o$704b2o$706bo8$755b2o$754b2o$
756bo171$907b3o$907bo$908bo7$912b2o$911b2o$913bo!
#C [[ AUTOSTART PAUSE 2 GRID "loaf2GtoG slow salvo\n34 gliders total" ]]
#C [[ T 1 X -445 Y -445 STEP 16 ZOOM 4 ]]
#C [[ LOOP 6000 ]]

Very slight changes (so slight that I can't figure out why they matter) seem to change the behavior of the viewer:

Code: Select all

x = 914, y = 945, rule = B3/S23
2o$2o4$3o$o$bo28$41b3o$41bo$42bo28$37b3o$37bo$38bo28$78b3o$78bo$79bo
28$74b3o$74bo$75bo28$115b3o$115bo$116bo28$132b3o$132bo$133bo3$193b3o$
193bo$194bo28$176b3o$176bo$177bo8$229b3o$229bo$230bo28$219b3o$219bo$
220bo8$271b3o$271bo$272bo28$244b2o$243b2o$245bo8$304b3o$304bo$305bo28$
304b2o$303b2o$305bo8$355b2o$354b2o$356bo28$354b2o$353b2o$355bo18$394b
3o$394bo$395bo28$402b3o$402bo$403bo28$440b3o$440bo$441bo28$471b3o$471b
o$472bo28$517b3o$517bo$518bo28$505b3o$505bo$506bo8$564b3o$564bo$565bo
28$545b3o$545bo$546bo8$603b2o$602b2o$604bo28$600b3o$600bo$601bo8$647b
3o$647bo$648bo28$625b3o$625bo$626bo8$673b2o$672b2o$674bo28$672b2o$671b
2o$673bo8$716b2o$715b2o$717bo28$705b2o$704b2o$706bo8$755b2o$754b2o$
756bo171$907b3o$907bo$908bo7$912b2o$911b2o$913bo!
#C [[ AUTOSTART GRID "loaf2GtoG slow salvo\n34 gliders total" ]]
#C [[ T 0 X -445 Y -445 STEP 16 ZOOM 4 ]]
#C [[ T 3535 "Construction complete" ]]
#C [[ LOOP 6000 ]]

I wanted to replace the last two lines with #C [[ T 3535 STEP 1 "Construction complete" LOOP 4000 ]], but that seems to have the same effect as adding a PAUSE -- the message and step-size change are showing up immediately.

[rowett]

Code: Select all

#C [[ AUTOSTART GRID "loaf2GtoG slow salvo\n34 gliders total" ]]
#C [[ T 0 X -445 Y -445 STEP 16 ZOOM 4 ]]
#C [[ T 3535 "Construction complete" ]]
#C [[ LOOP 6000 ]]

I wanted to replace the last two lines with #C [[ T 3535 STEP 1 "Construction complete" LOOP 4000 ]], but that seems to have the same effect as adding a PAUSE -- the message and step-size change are showing up immediately.

With with waypoint system you define the journey to the waypoint:
[[ T 3701 STEP 16 "HELLO" ]] means on the way to T=3701 use a STEP of 16 and display the message "HELLO".

Here's a version of your animation using PAUSE:

Code: Select all

#C [[ AUTOSTART GRID ]]
#C
#C define initial camera position before waypoints begin
#C [[ X -445 Y -445 ZOOM 4  ]]
#C
#C first waypoint is at T 3701, display a message and head there at STEP 16
#C [[ T 3701 STEP 16 "loaf2GtoG slow salvo\n34 gliders total" ]]
#C
#C now pause for 3 seconds while displaying "Construction Complete"
#C [[ PAUSE 3 "Construction complete" ]]
#C
#C loop at T 3702 after the pause
#C [[ LOOP 3702 ]]
x = 914, y = 945, rule = B3/S23
2o$2o4$3o$o$bo28$41b3o$41bo$42bo28$37b3o$37bo$38bo28$78b3o$78bo$79bo
28$74b3o$74bo$75bo28$115b3o$115bo$116bo28$132b3o$132bo$133bo3$193b3o$
193bo$194bo28$176b3o$176bo$177bo8$229b3o$229bo$230bo28$219b3o$219bo$
220bo8$271b3o$271bo$272bo28$244b2o$243b2o$245bo8$304b3o$304bo$305bo28$
304b2o$303b2o$305bo8$355b2o$354b2o$356bo28$354b2o$353b2o$355bo18$394b
3o$394bo$395bo28$402b3o$402bo$403bo28$440b3o$440bo$441bo28$471b3o$471b
o$472bo28$517b3o$517bo$518bo28$505b3o$505bo$506bo8$564b3o$564bo$565bo
28$545b3o$545bo$546bo8$603b2o$602b2o$604bo28$600b3o$600bo$601bo8$647b
3o$647bo$648bo28$625b3o$625bo$626bo8$673b2o$672b2o$674bo28$672b2o$671b
2o$673bo8$716b2o$715b2o$717bo28$705b2o$704b2o$706bo8$755b2o$754b2o$
756bo171$907b3o$907bo$908bo7$912b2o$911b2o$913bo!

Here's a version using a second waypoint:

Code: Select all

#C [[ AUTOSTART GRID ]]
#C
#C define initial camera position before waypoints begin
#C [[ X -445 Y -445 ZOOM 4  ]]
#C
#C first waypoint is at T 3701, display a message and head there at STEP 16
#C [[ T 3701 STEP 16 "loaf2GtoG slow salvo\n34 gliders total" ]]
#C
#C second waypoint is at T 4000, display "Construction complete" and head there at STEP 1
#C [[ T 4000 STEP 1 "Construction complete" ]]
#C
#C loop at T 4000
#C [[ LOOP 4000 ]]
x = 914, y = 945, rule = B3/S23
2o$2o4$3o$o$bo28$41b3o$41bo$42bo28$37b3o$37bo$38bo28$78b3o$78bo$79bo
28$74b3o$74bo$75bo28$115b3o$115bo$116bo28$132b3o$132bo$133bo3$193b3o$
193bo$194bo28$176b3o$176bo$177bo8$229b3o$229bo$230bo28$219b3o$219bo$
220bo8$271b3o$271bo$272bo28$244b2o$243b2o$245bo8$304b3o$304bo$305bo28$
304b2o$303b2o$305bo8$355b2o$354b2o$356bo28$354b2o$353b2o$355bo18$394b
3o$394bo$395bo28$402b3o$402bo$403bo28$440b3o$440bo$441bo28$471b3o$471b
o$472bo28$517b3o$517bo$518bo28$505b3o$505bo$506bo8$564b3o$564bo$565bo
28$545b3o$545bo$546bo8$603b2o$602b2o$604bo28$600b3o$600bo$601bo8$647b
3o$647bo$648bo28$625b3o$625bo$626bo8$673b2o$672b2o$674bo28$672b2o$671b
2o$673bo8$716b2o$715b2o$717bo28$705b2o$704b2o$706bo8$755b2o$754b2o$
756bo171$907b3o$907bo$908bo7$912b2o$911b2o$913bo!

[dvgrn]

With with waypoint system you define the journey to the waypoint...

Thanks! It's weird that I can never seem to remember that -- and also that I can successfully write entire long animations, like my most recent one, without actually understanding that detail properly.

EDIT: Cleaning up the LifeWiki, I'm just slightly puzzled by the behavior of the thumbnail for the Lobster. If I leave it up to the viewer to size it -- no width or height, or just a width, I get a viewer that's a little bit too small, with no gridlines visible.

HEIGHT 600 WIDTH 400 fixes the problem, but so does HEIGHT 600 WIDTH 600 -- and they both produce about the same (tall rectangular) viewer shape. Why isn't the second one square? I'll re-read Tiki bar explanations and see what I can figure out...

EDIT2: For the 7-in-a-row Cordership I had to make the height bigger than I wanted to get the zoom level I wanted, and really would have liked to widen it beyond what the Infobox defaults seem to allow. The current setup is kind of odd-looking, with blocks that look like they're popping up and down a few times per second. It would be nice to be able to override the autofit with an integer pixels-per-cell zoom level for this one.

[rowett]

Cleaning up the LifeWiki, I'm just slightly puzzled by the behavior of the thumbnail for the Lobster. If I leave it up to the viewer to size it -- no width or height, or just a width, I get a viewer that's a little bit too small, with no gridlines visible.

The default width and height for LifeViewer are 480x560 pixels. This can be overridden by the WIDTH and HEIGHT script commands. The minimum WIDTH allowed is 480. The minimum HEIGHT allowed is 240.
In thumbnail mode the width and height are then divided by the THUMBSIZE setting which can be 2, 3 or 4. For a default size LifeViewer that gives the following:

• THUMBSIZE 2 = 240x280
• THUMBSIZE 3 = 160x187
• THUMBSIZE 4 = 120x140

Looking at the Lobster page it has the following settings:

• WIDTH 400 (this is ignored since 400 is less than the minimum allowed width of 480)
• HEIGHT 600
• THUMBSIZE 2

We end up with a size of 240x300 which is 480x600 divided by the thumbsize of 2.

Grid lines only show up at zooms of 4x or greater. In the thumbnail you need to multiply this limit by the thumbsize. In the case above the natural zoom would need to by at least 8x to see grid lines in the thumbnail.

HEIGHT 600 WIDTH 400 fixes the problem, but so does HEIGHT 600 WIDTH 600 -- and they both produce about the same (tall rectangular) viewer shape. Why isn't the second one square?

Don't know. Nathaniel what are the default width and height for the canvas element? Is there a limit on the width of the canvas element in the template?

For the 7-in-a-row Cordership I had to make the height bigger than I wanted to get the zoom level I wanted, and really would have liked to widen it beyond what the Infobox defaults seem to allow. The current setup is kind of odd-looking, with blocks that look like they're popping up and down a few times per second. It would be nice to be able to override the autofit with an integer pixels-per-cell zoom level for this one.

Again Nathaniel will need to comment on the width. I'll have a look at adding something to enforce integer zoom.

[Nathaniel]

Nathaniel what are the default width and height for the canvas element? Is there a limit on the width of the canvas element in the template?

Again Nathaniel will need to comment on the width. I'll have a look at adding something to enforce integer zoom.

Hrm, I don't *think* I'm doing anything too weird with the canvas sizing, so I'm not entirely sure what's happening either. The default size is 200 wide and 300 high, but that's very arbitrary and I can change it if it's causing problems.

For what it's worth, all of the canvas code can be found at http://www.conwaylife.com/wiki/LV:Viewer (though you guys won't be able to edit that page).

[dvgrn]

Before the current workaround of changing RLE:coeship to a bigger phase, I tried fixing the Coe ship in various other ways, including using TRACKBOX.

It was originally (more or less)

Code: Select all

x = 10, y = 9, rule = B3/S23
4b6o$2b2o5bo$2obo5bo$4bo3bo$6bo$6b2o$5b4o$5b2ob2o$7b2o!
#C [[ THUMBNAIL AUTOSTART TRACKLOOP 64 1/2 0 GPS 4 ]]

and now it's

Code: Select all

x = 17, y = 10, rule = B3/S23
14b2o$o7bob4ob2o$o7bo2b5o$8bo3b3o$2bo$2bo$12b4o$11bo3bo$15bo$11bo2bo!
#C [[ THUMBNAIL AUTOSTART TRACKLOOP 64 1/2 0 GPS 4 ]]

but I also tried the following, hoping to define a different starting bounding box to start from. No luck -- it looks the same as the first one above:

Code: Select all

x = 10, y = 9, rule = B3/S23
4b6o$2b2o5bo$2obo5bo$4bo3bo$6bo$6b2o$5b4o$5b2ob2o$7b2o!
#C [[ THUMBNAIL AUTOSTART ZOOM 10 X -4 Y 0 TRACKBOX 1/2 0 1/2 0 GPS 4 ]]

Also, I got some strange behavior when I accidentally put the ESWN parameters in the wrong order. At around T=13, the zoom level starts gradually going down (as it should)... but at T=18 or so, the viewer suddenly jumps to a zoom level of -16 (?!?) and sticks there.

Code: Select all

x = 10, y = 9, rule = B3/S23
4b6o$2b2o5bo$2obo5bo$4bo3bo$6bo$6b2o$5b4o$5b2ob2o$7b2o!
#C [[ THUMBNAIL AUTOSTART ZOOM 20 X -4 Y 0 TRACKBOX 1/2 1/2 0 0 GPS 4 ]]

EDIT: I still like my version of the 7-in-a-row Cordership better, though I admit that the viewer is too tall, and it's also a little weird-looking to have the blocks changing size all the time. I'm not sure if it will require a new build of LifeViewer, or possibly just new default parameters for the Infobox (?), to get that Cordership to show up at that same zoom level in a smaller box.

[rowett]

but I also tried the following, hoping to define a different starting bounding box to start from. No luck -- it looks the same as the first one above

Yes because the AutoFit modes start from the T=0 pattern bounding box. Setting the camera position manually makes no difference.

Also, I got some strange behavior when I accidentally put the ESWN parameters in the wrong order. At around T=13, the zoom level starts gradually going down (as it should)... but at T=18 or so, the viewer suddenly jumps to a zoom level of -16 (?!?) and sticks there.

Yes because you told the South edge of the box to move north (at 1/2 cell/generation) and after 18 generations it had crossed the North edge of the box which was static. The Viewer wasn't expecting the bounding box to flip.

[rowett]

Hrm, I don't *think* I'm doing anything too weird with the canvas sizing.

No you weren't, it was LifeViewer.

LifeViewer on the forum limits its width to the width of the codebox. It's trying to do the same on the Wiki but in this case the codebox is not displayed so has a width of 0. Fortunately at that point LifeViewer enforces the 240 pixel minimum width.

The good news is that this behaviour is configurable via a meta tag on the web page. If you add

Code: Select all

<meta name="LifeViewer" content="rle code">

in the <head> section of the Wiki webpage it will disable the limit function and LifeViewer will grow the canvas width to the WIDTH specified (up to a maximum of 1024 pixels).

I've also fixed a small issue in the bounding box vertical calculation which should make some patterns slightly larger when AutoFit. The new build is below. I'm still thinking about the integer zoom / fix zoom requirement.

[rowett]

Build 201 is now available on the lazyslug server

Fixes in this build:

• the vertical bounding box calculation was slightly incorrect for AutoFit

[dvgrn]

I'm still thinking about the integer zoom / fix zoom requirement.

My wishful-thinking test above, changing the view at T=0, makes me wonder if TRACKBOX really needs to be an AutoFit variant. What if TRACKBOX just started with whatever view it found at T=0? (And would TRACK and TRACKLOOP really need to be different from TRACKBOX, in that case?)

If no custom view is specified, the default view would still end up being fitted to the pattern. But it would be easy to define a different camera location, or a different zoom level (which is what I've been wishing for the most often in my last half-day of LifeWiki Infobox fixes.)

I might as well mention, while I'm being annoying, that I'm very happy that the pop-up viewers launched by the Infobox thumbnails now no longer have their GPS and STEP controls locked down. But I sure do fumble uselessly with the mouse-wheel zoom control a lot, for whatever reason. Seems like I instinctively accept the new frame of reference, in which Corderships-or-whatever are stationary oscillators, but still lifes drift steadily away -- and I'd like to be able to change the zoom and click-and-drag to recenter, all in that new frame of reference.

Code: Select all

I had a frame of reference
I set it on a fence
Along came relativity
Ain't seen the damn thing since --
Ain't seen the damn thing since.

Albert, dance around
Albert, be profound
Albert, let your hair stick up, your
Socks
Hang
Down.

Another random note: it takes an impressively long time to run a Cordership off the edge of the grid. (The 7-in-a-row one currently uses TRACKBOX instead of TRACKLOOP.) Once it does, it might actually make sense to reset the viewer automatically (?).

[rowett]

[My wishful-thinking test above, changing the view at T=0, makes me wonder if TRACKBOX really needs to be an AutoFit variant. What if TRACKBOX just started with whatever view it found at T=0? (And would TRACK and TRACKLOOP really need to be different from TRACKBOX, in that case?)

Actually TRACKLOOP is just TRACK with a LOOP, and TRACK X Y is implemented under the covers as TRACKBOX X Y X Y. What I'm trying to say is that they're all the same in a sugary syntactic sort of way.

If no custom view is specified, the default view would still end up being fitted to the pattern. But it would be easy to define a different camera location, or a different zoom level (which is what I've been wishing for the most often in my last half-day of LifeWiki Infobox fixes.)

Yes I could make the start position the T=0 camera position. I'll investigate.

I'd like to be able to change the zoom and click-and-drag to recenter, all in that new frame of reference.

So you want TRACKBOX to define a new dynamic origin. Would you like fries with that?

Another random note: it takes an impressively long time to run a Cordership off the edge of the grid. (The 7-in-a-row one currently uses TRACKBOX instead of TRACKLOOP.) Once it does, it might actually make sense to reset the viewer automatically (?).

Two things:

1. You should be using TRACKLOOP
2. I could potentially add a script command to define what happens when a pattern hits the boundary
   • Delete using DELETERANGE (the default)
   • Reset
   • Stop
   • Something unusual Dave is about to dream up...

[dvgrn]

So you want TRACKBOX to define a new dynamic origin. Would you like fries with that?

Well, now, hang on, don't put f̶r̶i̶e̶s̶ words in my mouth here. It was only a thought experiment...

TRACKBOX in particular is supposed to be good for patterns that grow or change size in weird ways -- as you say, for a plain old Cordership I should be using TRACKLOOP. I'll go fix that on the Wiki later.

I guess what I'm saying is that the simpler TRACK/TRACKLOOP use cases could be handled very nicely if there was an option to define a dynamic origin -- DX, DY = 0, 0 by default of course.

Then the regular old LOOP option could take care of not running off the edge of the grid. There wouldn't be any particular temptation to have to lock down the zoom level or other viewer controls, because (maybe?) they would all work "the same way" no matter what the dynamic-origin setting was.

Two things:

1. You should be using TRACKLOOP
2. I could potentially add a script command to define what happens when a pattern hits the boundary
   • Delete using DELETERANGE (the default)
   • Reset
   • Stop
   • Something unusual Dave is about to dream up...

I always feel a little embarrassed to add to the feature-creep problem -- especially when I end up having to test the resulting changes.

So let me just take that last comment back: I don't particularly want that new script command, and as far as I know, nobody else really needs it either...!

[rowett]

Build 202 is now available on the lazyslug server

Fixes in this build:

• Generations rules were failing to draw some decay states at T=0 - test

[rowett]

I guess what I'm saying is that the simpler TRACK/TRACKLOOP use cases could be handled very nicely if there was an option to define a dynamic origin -- DX, DY = 0, 0 by default of course.

I've got a prototype up and working and it's looking promising. If it works well you can probably have a side salad with your fries.
Dynamic origin could just act as an implementation replacement for TRACK (and TRACKLOOP). TRACKBOX will remain as an AutoFit variant since it needs to adjust ZOOM.

Won't be able to upload any builds this week while I'm away so I'm spending the week tidying up some of the items below on the backlog:

• complete support for #CXRLE Pos
• make Generations patterns die properly when they hit the boundary
• accurate "Life ended at" generation when STEP > 1
• investigate whether bounded grids have the correct population count
• make Step Forward/Step Back work a generation at a time with Waypoints and add Time Forward/Time Back controls

The bigger items that I'll eventually get to are:

• Golly hensel2 support
• LifeViewerGL (the WebGL version)
• pattern editor
• VIC20 mode

[dvgrn]

The bigger items that I'll eventually get to are:

• Golly hensel2 support

I'd certainly like to see isotropic rule support find its way into Golly 2.8, if that's possible -- just because it's hard to know when the next Golly release will end up being, and it would be really nice to get Golly to match LifeViewer on that point. Let me know if there's anything I can do to help there.

[*]VIC20 mode[/list]

Eh? You'll switch to a font with fixed-width characters that are all wider than they are tall... or what?

(That was a really weird design decision for the VIC20 -- even back then it seemed very odd that there were 23 rows with only 22 characters in each. It wasn't as if TV screens were taller than they were wide, or anything...)

[rowett]

That was a really weird design decision for the VIC20 -- even back then it seemed very odd that there were 23 rows with only 22 characters in each. It wasn't as if TV screens were taller than they were wide, or anything...

And even better it had a lower(!) resolution mode where the 8x8 characters became 4x8 but became multi(3)-colour.

The VIC20 was my first computer so it seems only fitting to build a VIC20 display mode into LifeViewer. In double height character mode you could effectively create a 160x160 bitmap display using a user defined character set.

Fortunately for all concerned I doubt this will surface until builds get into 4 digits...

[dvgrn]

The VIC20 was my first computer so it seems only fitting to build a VIC20 display mode into LifeViewer. In double height character mode you could effectively create a 160x160 bitmap display using a user defined character set.

Fortunately for all concerned I doubt this will surface until builds get into 4 digits...

I'll wait until Build 1000 to put in my TRS-80 display mode feature request, then. A TRS-80 Model 1 was my first computer, and it had an equally ridiculous graphics system, where each character on a 64x16 screen was split into a 2x3 grid, which meant a 128x48 display with the pixels twice as tall as they were wide.

My first experience with Life was pictures of patterns using these strange stretched pixels as cells:

80Microcomputing_0680_0000.jpg (143.96 KiB) Viewed 138 times

[rowett]

A TRS-80 Model 1 was my first computer...

You may enjoy TRS 80 Life that I found earlier today.

Cursor keys to move/erase.
Shift @ and Cursor keys to draw.
Enter to start playback.
Esc to reset.

[dvgrn]

A TRS-80 Model 1 was my first computer...

You may enjoy TRS 80 Life that I found earlier today.

Huh. I wonder what rule it's running. It's not quite B3/S23, because Herschels and pi heptominoes don't have the right final form.

And Shift+@+down arrow doesn't work, but it's easy to work around that...!

[rowett]

I've got a prototype up and working and it's looking promising. If it works well you can probably have a side salad with your fries.
Dynamic origin could just act as an implementation replacement for TRACK (and TRACKLOOP). TRACKBOX will remain as an AutoFit variant since it needs to adjust ZOOM.

Dynamic Origin has now replaced AutoFit for TRACK and TRACKLOOP. The benefit is that all controls are still available and AutoFit can just be used to recenter the pattern once you've zoomed or panned away.
Do you think it will be necessary to allow Dynamic Origin to be toggled on and off (like hotkey "w" for Waypoints or LOOP) and turned off on first Reset and back on during second Reset?

I'm also considering also using Dynamic Origin for TRACKLOOP by extending the origin X, Y to have a Z component. Not quite sure what to do with the ZOOM slider yet...