Golly 2.8 has been released

[Andrew]

Golly 2.8 can be downloaded from Sourceforge:

https://sourceforge.net/projects/golly/ ... golly-2.8/

People using version 2.8b3 should definitely upgrade. We've fixed a few bugs and added support for non-totalistic rules (see Help > Algorithms > QuickLife).

EDIT: I forgot to mention that you can go to Help > Online Archives > Very Large Patterns and download David Bell's collection of patterns using the "Just Friends" rule (B2-a/S12).

[FlameandFury]

Hype!!!!! Right now using iPad because of vacation, but going to get this when I get back home. I believe non-totalistic rules will experience a huge rise in popularity, which is good because lots of those rules are quite interesting.

[gameoflifeboy]

Oh, no!!!

Okay, I guess I should have mentioned this earlier. I've been having a problem with 64-bit Golly 2.8 since this beta release and this problem has not gone away in the full release. 32-bit isn't doing any better either.

The problem is quite simple. On my laptop (Windows 8.1), there are many applications that open "blurry" windows when ran, in the sense that one pixel of the application covers multiple pixels of the screen. I was quite relieved when 64-bit Golly 2.7 avoided this problem, as the patterns are much easier to watch when each cell covers one pixel, but now Golly 2.8 has it! Here is a screenshot:

golly2.8problem.png (124.62 KiB) Viewed 22611 times

Worse yet, in Biggiemac's post about a bug in Golly on Windows 10, the Golly versions that he mentions as having the bug (Golly 2.7 and the beta releases of Golly 2.8 before July 19), are the exact versions that look fine to me. So it seems that Biggiemac's problem was caused by whatever kept my problem from happening.

Can you please provide me with a solution to this problem? There is an Ubuntu computer in my house but I cannot use it very much.

[flipper77]

I can't seem to find how to show the list of scripts I have on the left side of the window like 2.7 and previous, I'm guessing that's unintentional, or am I just missing something?

[Andrew]

I can't seem to find how to show the list of scripts I have on the left side of the window like 2.7 and previous, I'm guessing that's unintentional, or am I just missing something?

Quoting from item 5 in Help > Changes: "The File menu items Show Patterns and Show Scripts have been replaced by a single Show Files item for consistency with the recommended way to organize your Golly folder." See Help > Hints and Tips for the recommended way.

Note that if you really want the ability to see more than one folder you can do it by writing some simple scripts and assigning suitable keyboard shortcuts to them. For example, I have option-S and option-A assigned to these 2 scripts:

show-scripts.lua:

Code: Select all

local g = golly()
g.setdir("files", g.getdir("app").."Scripts/Lua")

show-appdir.lua:

Code: Select all

local g = golly()
g.setdir("files", g.getdir("app"))

I used the 1st script quite a lot when I was writing all the Lua scripts. Now I never use it and just show the full application folder.

[Andrew]

Okay, I guess I should have mentioned this earlier.

Yes, you should have!

The problem is quite simple. On my laptop (Windows 8.1), there are many applications that open "blurry" windows when ran, in the sense that one pixel of the application covers multiple pixels of the screen. I was quite relieved when 64-bit Golly 2.7 avoided this problem, as the patterns are much easier to watch when each cell covers one pixel, but now Golly 2.8 has it!

I'm not convinced there really is a problem. Golly doesn't attempt to check for a high-res monitor (the wxWidgets folks are still struggling with the best way to do that), so Windows is automatically scaling up Golly's text, bitmaps, etc., so that things don't look too small.

Can you please post another screenshot showing what Golly 2.7 looks like on your monitor? Use the same scale (1:16) and other settings so I can easily compare the 2 images. There might be some sort of hack you can try that involves modifying the manifest info embedded in Golly.exe.

[gameoflifeboy]

Here is the screenshot from Golly 2.7, at a scale of 1:16. Notice that the cell boundaries are only one pixel wide (and not anti-aliased).

golly2.7noproblem.png (146.08 KiB) Viewed 22531 times

Similarly, here is a comparison between how versions 2.8 (left) and 2.7 (right) display a glider at scale 1:1. I think the version on the right is definitely clearer.

twogliders.png (383 Bytes) Viewed 22531 times

EDIT: "one pixel wide" instead of "one cell wide"

[Andrew]

Here is the screenshot from Golly 2.7...

Interesting -- thanks for doing that. It looks like everything in Golly 2.8 is being scaled up by 25%. I'm not really sure why Windows is doing that but I suspect it's probably due to the manifest info in the 2.8 exe. I'm pretty sure the 2.7 exe doesn't have any manifest info. I think there are tools you can use to remove a manifest from an exe file, so that might be one thing you could try doing.

EDIT: Removed link to ResEdit as it wasn't able to delete manifest.

I didn't build the 64-bit exe for Golly 2.7 so can you please do these steps: Start up Golly 2.7, quit it, then open its GollyPrefs file in a text editor (the file will either be in the same folder as the exe or else in C:\Users\username\AppData\Roaming\Golly\). Please tell me what the wx_version setting says (its near the top).

[gameoflifeboy]

Okay. I just opened and closed Golly 2.7, and then opened GollyPrefs. It says: "wx_version=wxWidgets 3.0.2".

[Andrew]

Okay. I just opened and closed Golly 2.7, and then opened GollyPrefs. It says: "wx_version=wxWidgets 3.0.2".

Thanks for that. That's the version I used to build 2.8 so we can rule that out as a possible problem.

I've managed to locate a (free) utility that can successfully delete the manifest info from Golly.exe:

http://www.angusj.com/resourcehacker/#download

It's very simple to use. Run it, open Golly.exe, select the Manifest item, delete it via the Action menu, then Save from the File menu. Now try running Golly.exe and I suspect it should look like 2.7. Let me know!

[Rocknlol]

I'm finding that on large, chaotic patterns, like a soup in 3-4 Life, Golly will run at different speeds based on my zoom level. 1:2, particularly, is noticeably slower than 1:1. Could this be related to the switch to OpenGL for pattern rendering?

[drc]

I'm finding that on large, chaotic patterns, like a soup in 3-4 Life, Golly will run at different speeds based on my zoom level. 1:2, particularly, is noticeably slower than 1:1. Could this be related to the switch to OpenGL for pattern rendering?

That happens in 2.7 too...

[toroidalet]

It's so sad that Golly 2.8 doesn't support non-totalistic B0 rules. , but here's a simple fix that won't probably take too long... When you invert the presence of transitions, invert everything but the non-totalistic transitions. For those transitions, invert the presence of a minus sign. An example of this in action would be turning B0124-k/S125 (I like rules close to B0124/S0125) into B34k5678/S034678. For inverting the neighbors in the transitions and swapping birth with survival, do the same for transitions with letters (and maybe minus signs) with the exception of 4. For non-totalistic transitions with a 4, swap 4e with 4c, 4i with 4t, 4n with 4r, 4y with 4j, and 4w with 4q, but don't invert the presence of minus signs in this case. (4a, 4k, and 4z remain the same) Otherwise, execute permutations the same as for totalistic B0 rules. For the example above, the odd-generation rule would be B367/S4-k678. Aside from this bit for improvement, Golly version 2.8 is the same or better than 2.7 in most things. Great Job!

[gameoflifeboy]

Okay. I just opened and closed Golly 2.7, and then opened GollyPrefs. It says: "wx_version=wxWidgets 3.0.2".

Thanks for that. That's the version I used to build 2.8 so we can rule that out as a possible problem.

I've managed to locate a (free) utility that can successfully delete the manifest info from Golly.exe:

http://www.angusj.com/resourcehacker/#download

It's very simple to use. Run it, open Golly.exe, select the Manifest item, delete it via the Action menu, then Save from the File menu. Now try running Golly.exe and I suspect it should look like 2.7. Let me know!

Okay, I just deleted the Manifest item, and the new version of Golly still has the scaling problem. The only difference seems to be that the buttons have changed style (they now look the same as the buttons in 64-bit 2.7 where they previously looked like the 2.6 buttons).

[rowett]

... the new version of Golly still has the scaling problem.

I'm using Golly 2.8 on Windows 10 64bit and have windows scaling set to 125% and get the same display as you. If I set windows scaling back to 100% all is well.

[Andrew]

Okay, I just deleted the Manifest item, and the new version of Golly still has the scaling problem.

A pity. One more thing to try... Go back to the original Golly 2.8 that has the manifest. Open Golly.exe in ResourceHacker and select the Manifest item as before, but this time insert the following lines into the manifest text just before the final </assembly> line:

Code: Select all

<asmv3:application>
  <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
    <ms_windowsSettings:dpiAware xmlns:ms_windowsSettings="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</ms_windowsSettings:dpiAware>
  </asmv3:windowsSettings>
</asmv3:application>

Save the changes and see what happens when you start up this modified Golly.exe.

EDIT: If that doesn't work then I think you have no option but to do as Chris suggests and set the scaling to 100%.

[drc]

try typing "B3/S23-" in the rule field

[Andrew]

try typing "B3/S23-" in the rule field

Thanks for the report. The bug (fortunately very minor) has been fixed for the next release.

[gameoflifeboy]

Okay, I just deleted the Manifest item, and the new version of Golly still has the scaling problem.

A pity. One more thing to try... Go back to the original Golly 2.8 that has the manifest. Open Golly.exe in ResourceHacker and select the Manifest item as before, but this time insert the following lines into the manifest text just before the final </assembly> line:

Code: Select all

<asmv3:application>
  <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
    <ms_windowsSettings:dpiAware xmlns:ms_windowsSettings="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</ms_windowsSettings:dpiAware>
  </asmv3:windowsSettings>
</asmv3:application>

Save the changes and see what happens when you start up this modified Golly.exe.

EDIT: If that doesn't work then I think you have no option but to do as Chris suggests and set the scaling to 100%.

It didn't work. Here is the manifest text after modification:

Code: Select all

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
    version="0.64.1.0"
    processorArchitecture="amd64"
    name="Controls"
    type="win32"
/>
<description>wxWindows application</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="amd64"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
<asmv3:application>
  <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
    <ms_windowsSettings:dpiAware xmlns:ms_windowsSettings="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</ms_windowsSettings:dpiAware>
  </asmv3:windowsSettings>
</asmv3:application>
</assembly>

On the other hand, Chris Rowett's suggestion did work! I have now used it not only on Golly but on other applications that had the same problem.

[rowett]

It's so sad that Golly 2.8 doesn't support non-totalistic B0 rules. , but here's a simple fix that won't probably take too long... When you invert the presence of transitions, invert everything but the non-totalistic transitions. For those transitions, invert the presence of a minus sign. An example of this in action would be turning B0124-k/S125 (I like rules close to B0124/S0125) into B34k5678/S034678. For inverting the neighbors in the transitions and swapping birth with survival, do the same for transitions with letters (and maybe minus signs) with the exception of 4. For non-totalistic transitions with a 4, swap 4e with 4c, 4i with 4t, 4n with 4r, 4y with 4j, and 4w with 4q, but don't invert the presence of minus signs in this case. (4a, 4k, and 4z remain the same) Otherwise, execute permutations the same as for totalistic B0 rules. For the example above, the odd-generation rule would be B367/S4-k678.

Sorry I didn't understand all of that, especially the "and maybe minus signs" bit. Currently totalistic B0 rules are handled as follows:

• If original rule has B0 but not S8:
  • For even generations, whenever the original rule has a Bx or Sx, omit that bit from the modified rule, and whenever the original rule is missing a Bx or Sx, add that bit to the modified rule.
    eg. B03/S23 => B1245678/S0145678.
  • For odd generations, use Bx if and only if the original rule has S(8-x) and use Sx if and only if the original rule has B(8-x).
    eg. B03/S23 => B56/S58.
• If original rule has B0 and S8:
  • Such rules don't strobe, so we just want to invert all the cells. The trick is to do both changes: invert the bits, and swap Bx for S(8-x).
    eg. B03/S238 => B123478/S0123467 (for ALL gens).

If some kind soul could have a go at updating the above for the non-totalistic rules I'll have a go at implementing it.

[dvgrn]

If some kind soul could have a go at updating the above for the non-totalistic rules I'll have a go at implementing it.

Let's see how well I can do at re-translating toroidalet's impressive single paragraph into bite-sized chunks. I think everything in that paragraph is correct, just really hard to interpret...!

The long text below is mostly just me explaining everything to myself (because to be honest, as I'm writing this sentence I don't really understand it very well yet.)

--------------------------------------

Let's start with this idea: every totalistic rule can be written as an isotropic non-totalistic rule.

In totalistic space there are 18 bits. [B0 ... B8] and [S0 ... S8] can each be either present in the rule, or not.

In isotropic non-totalistic space there are 102 bits. [B0, B1c ... B7e, B8] and [S0, S1c ... S7e, S8] can be present in the rule, or not. Here's the full list:

B0 = B0 (i.e., there's still only one way for a cell to have zero neighbors)
B1 = B1c, B1e
B2 = B2c, B2e, B2k, B2a, B2i, B2n
B3 = B3c, B3e, B3k, B3a, B3i, B3n, B3y, B3q, B3j, B3r
B4 = B4c, B4e, B4k, B4a, B4i, B4n, B4y, B4q, B4j, B4r, B4t, B4w, B4z
B5 = B5c, B5e, B5k, B5a, B5i, B5n, B5y, B5q, B5j, B5r
B6 = B6c, B6e, B6k, B6a, B6i, B6n
B7 = B7c, B7e
B8 = B8

S0 = S0
S1 = S1c, S1e
S2 = S2c, S2e, S2k, S2a, S2i, S2n
S3 = S3c, S3e, S3k, S3a, S3i, S3n, S3y, S3q, S3j, S3r
S4 = S4c, S4e, S4k, S4a, S4i, S4n, S4y, S4q, S4j, S4r, S4t, S4w, S4z
S5 = S5c, S5e, S5k, S5a, S5i, S5n, S5y, S5q, S5j, S5r
S6 = S6c, S6e, S6k, S6a, S6i, S6n
S7 = S7c, S7e
S8 = S8

For example, good old B3/S23 could be thought of as this collection of isotropic bits:

B3c, B3e, B3k, B3a, B3i, B3n, B3y, B3q, B3j, B3r /
S2c, S2e, S2k, S2a, S2i, S2n
S3c, S3e, S3k, S3a, S3i, S3n, S3y, S3q, S3j, S3r

So we could write B3/S23 in correct but not canonical isotropic format as B3cekainyqjr/S2cekain3cekainyqjr:

Code: Select all

x = 3, y = 3, rule = B3cekainyqjr/S2cekain3cekainyqjr
obo$obo$3o!
#C [[ AUTOSTART AUTOFIT HISTORYFIT ]]

A minus sign is just syntactic sugar for something that could equally well be written in a longer form. B3-k is "all B3 isotropic bits are ON except for B3k". So I'm relieved to find that this non-canonical rule name works fine in LifeViewer:

Code: Select all

x = 3, y = 3, rule = B3-/S2-3-
obo$obo$3o!
#C [[ AUTOSTART AUTOFIT HISTORYFIT ]]

Because of the symmetrical way that Alan Hensel organized the "neighbors2" table, for every isotropic bit besides the B4[alpha] and S4[alpha] bits, [B|S][digit][alpha] is the inversion of [S|B][8-digit][alpha]. In other words, the lowercase letter only has to change for the 4-neighbor cases that toroidalet mentioned:

...swap 4e with 4c, 4i with 4t, 4n with 4r, 4y with 4j, and 4w with 4q, but don't invert the presence of minus signs in this case. (4a, 4k, and 4z remain the same).

Now it looks like the current handling of totalistic rules can be adjusted to include isotropic rules, without too much trouble:

• If original rule has B0 but not S8:
  • For even generations,
    for each B[digit][alpha] or S[digit][alpha] in the original rule, omit that bit from the modified rule,
    and for each missing B[digit][alpha] or S[digit][alpha], add that bit to the modified rule.
    
    Thanks to the minus-sign syntactic sugar in isotropic rule format, this generally just means adding a minus sign in front of each group of letters, and removing any existing minus sign in front of a group of letters -- e.g., B0124-k/S1c25 => B34k5678/S01-c34678.
  • For odd generations,
    • for everything except 4-neighbor isotropic bits,
      use B[digit][alpha] if and only if the original rule has S[8-digit][alpha],
      and use S[digit][alpha] if and only if the original rule has B[8-digit][alpha].
    • for 4-neighbor isotropic bits, use the following table:

      Code: Select all

      4c -> 4e
      4e -> 4c
      4k -> 4k
      4a -> 4a
      4i -> 4t
      4n -> 4r
      4y -> 4j
      4q -> 4w
      4j -> 4y
      4r -> 4n
      4t -> 4i
      4w -> 4q
      4z -> 4z

• If original rule has B0 and S8:
  • Such rules don't strobe, so we just want to invert all the cells. The trick is to do both changes: invert the isotropic bits, and swap B[digit][alpha] for S[8-digit][alpha], plus the special 4-neighbor isotropic bit swap shown in the above table.

If it's easier, the 4-neighbor swap table could be expanded to list all 51 types of isotropic bits, and the canonical form of the rule could be figured out as a separate step.

--------------------------------------

I definitely don't guarantee that this will actually work, but it seems plausible, and it's a testable hypothesis...!

[LegionMammal978]

Running this on 64-bit Ubuntu, I'm experiencing major slowdowns while zooming in/out as opposed to 2.7. Additionally, holding down spacebar for a speed between 0.25s and unit step also just freezes.

[drc]

I have a candidate for a pattern:

Code: Select all

#C A (29,4)c/110 pyramid generator, found by Daniel R. Collazo
x = 4, y = 4, rule = B34t/S23-a4i6cik7
bo$obo$2bo$3bo!

[rowett]

If original rule has B0 but not S8:

• For even generations,
  for each B[digit][alpha] or S[digit][alpha] in the original rule, omit that bit from the modified rule,
  and for each missing B[digit][alpha] or S[digit][alpha], add that bit to the modified rule.
  
  Thanks to the minus-sign syntactic sugar in isotropic rule format, this generally just means adding a minus sign in front of each group of letters, and removing any existing minus sign in front of a group of letters -- e.g., B0124-k/S1c25 => B34k5678/S01-c34678.
• For odd generations,
  • for everything except 4-neighbor isotropic bits,
    use B[digit][alpha] if and only if the original rule has S[8-digit][alpha],
    and use S[digit][alpha] if and only if the original rule has B[8-digit][alpha].
  • for 4-neighbor isotropic bits, use the following table:

    Code: Select all

    4c -> 4e
    4e -> 4c
    4k -> 4k
    4a -> 4a
    4i -> 4t
    4n -> 4r
    4y -> 4j
    4q -> 4w
    4j -> 4y
    4r -> 4n
    4t -> 4i
    4w -> 4q
    4z -> 4z

Based on the above are the following what you expect:

Code: Select all

rule: B0124cik/S1c25  even: B34-cik5678/S01-c34678  odd: B367c/S4etk678
rule: B0124-k/S1c25   even: B34k5678/S01-c34678     odd: B367c/S4-k678
rule: B0124-ci/S1c25  even: B34ci5678/S01-c34678    odd: B367c/S4-et678

[dvgrn]

Based on the above are the following what you expect:

Code: Select all

rule: B0124cik/S1c25  even: B34-cik5678/S01-c34678  odd: B367c/S4etk678
rule: B0124-k/S1c25   even: B34k5678/S01-c34678     odd: B367c/S4-k678
rule: B0124-ci/S1c25  even: B34ci5678/S01-c34678    odd: B367c/S4-et678

Yup. For odd generations, 4ci would change to 4et, and that means that 4-ci changes to 4-et ... it all makes sense, in theory.

To see whether the theory works out in practice, once the above flicker-stopping trickery is implemented, it would be good to also have a way to run the actual rule in all its headache-inducing glory.

If we pick a few dozen random rules with random patterns, run the flicker-free workaround and the actual rule on the same-sized torus, and always get the same final pattern at say T=1000, then that would be a very good sign that we haven't made any mistakes in the algorithm...!