Gargoyle and a large WIP

[Emily Short]

Also posted to the intfiction forum, but I realized this might be more efficient:

I have a large puzzle game this><far from completion. 

Unfortunately, my testers are reporting that UNDO doesn't work in Gargoyle across the board (Mac, Windows, or Linux). Mac Zoom and Windows Glulxe do appear to offer UNDO, but I know a lot of players default to Gargoyle, so I'd like to get the Gargoyle experience right there. As far as we can tell there are no Linux terps at all that run the game exactly as I would hope (reasonable turn speed, optional graphics displayed, and UNDO functional).

My best guess here is that Gargoyle is assigning a buffer for saving game-state that is too small, given a very big and fiddly world model. I could be wrong, but batting this around with people on ifMUD, it sounds like that might be the problem.

Are there any Gargoyle maintainers who would be up for having a look and who might be able to tweak the build if that is indeed the solution? I'd be happy to send over a copy of the game file, put your name in the credits, buy you a beer when we're next at the same town/conference, etc.

[Ben Cressey]

Gargoyle's default Glulx interpreter is Git, and there's a hard-coded undo buffer size in its startup code:

https://code.google.com/p/garglk/source/browse/trunk/terps/git/git_unix.c#28

This seems like the most likely culprit. By contrast, Glulxe uses an undo buffer with 8 slots rather than a cap on memory allocation.

Do you know if WinGit handles undo properly? If so I can just borrow whatever defaults David Kinder is using there.

Another approach would be to override the Glulx terp using a <gamename>.ini file in the same directory as the game, with these contents:

[ <gamename>.gblorb ]
terp glulxe

The result may not meet the other criteria (reasonable turn speed) but it would help confirm an interpreter issue vs. a Glk implementation problem. 

--
You received this message because you are subscribed to the Google Groups "garglk-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/garglk-dev/-/HodX-AFUFd4J.
To post to this group, send email to gargl...@googlegroups.com.
To unsubscribe from this group, send email to garglk-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/garglk-dev?hl=en.

[Emily Short]

Testers report that WinGit doesn't handle UNDO either.

[Emily Short]

...okay, and I've now done the .ini thing and confirmed that that does indeed make the game play more slowly but with functional UNDO. So it sounds as though the diagnostics are correct.

Is there a way to figure out how large the buffer needs to be?

On Saturday, December 29, 2012 6:40:00 PM UTC-8, Ben Cressey wrote:

[Ben Cressey]

On Sat, Dec 29, 2012 at 7:08 PM, Emily Short <ems...@mindspring.com> wrote:

...okay, and I've now done the .ini thing and confirmed that that does indeed make the game play more slowly but with functional UNDO. So it sounds as though the diagnostics are correct.

Is there a way to figure out how large the buffer needs to be?

Not easily. Git takes a different approach to saving undo data: the first undo record takes a diff of the current game state vs the state captured in the game file. So a lot of "when play begins" type rules that shuffle state early on could make that first snapshot very large. Subsequent undo records do a diff against the most recent record; the main factor there is how much state is changing between turns.

This is probably why Git doesn't have configurable undo slots: in games where state change between turns is minimal, the diff approach could store an effectively unlimited number of undo records.

Anyhow the question is whether the default undo buffer just needs to be raised to a new, modestly higher number like 5 MB vs 512 KB, to get the game over the initial hurdle of recording its first memory snapshot - or whether every turn is generating enough state change that the buffer would need to be far higher to hold a reasonable number of diffs (undo records).

It's tempting to parameterize the cacheSize and undoSize values discussed here:

https://code.google.com/p/garglk/source/browse/trunk/terps/git/README.txt#102

But those are somewhat fiddly knobs to expect authors and players to tune via ini files, so if we can come up with better defaults then I'm OK with the larger memory footprint for everything. At a first pass I can do a build with a 10 MB undo buffer (to get undo working, and see how many turns' worth of undo it buys us) and a 512 KB cache size (to see if that helps Git's overall performance).

What platform would a custom build need to target to be most useful for testing, Windows or OS X? (I assume Linux testers could just patch the source code & recompile Gargoyle.)

 

[Dannii Willis]

Maybe just the dynamic memory size? It would at least give you the maximum you'd need.

Use the -z compiler switch, -s doesn't seem to have the info. Possibly the Mac IDE will use the switch already, if it doesn't you can add this to your Inform 7 code:

Include (- Switches z; -) before "Other Configuration" in "Output.i6t".

[Emily Short]

I'm on OS X, so that's the easiest for me to test myself; Windows builds I'd have to ship off to my betatesters for analysis. 

There's a large amount of caching right at start-up, which would indeed mean a significant difference between the startup state and the first-move state. In theory I could build that cache once and hard-code it. That's a pain in the ass maintenance-wise because it has to be reconstructed every time the game is rereleased, so if there are other options that would be grand.

[Emily Short]

That produces the following chart:

        +---------------------+   000000

Read-   |       header        |

 only   +=====================+   000024

memory  |  memory layout id   |

        +---------------------+   00003c

        |        code         |

        +---------------------+   1ec7cb

        | string decode table |

        + - - - - - - - - - - +   1ecc92

        |       strings       |

        +=====================+   290600

Dynamic |  global variables   |

memory  + - - - - - - - - - - +   2909ac

        |       arrays        |

        +---------------------+   426bfd

        | printing variables  |

        +---------------------+   426c01

        |       objects       |

        + - - - - - - - - - - +   437f61

        |   property values   |

        + - - - - - - - - - - +   60b0e5

        |  property defaults  |

        + - - - - - - - - - - +   60b185

        | class numbers table |

        + - - - - - - - - - - +   60b421

        |   id names table    |

        +=====================+   60d83d

Readable|    grammar table    |

memory  + - - - - - - - - - - +   610481

        |       actions       |

        + - - - - - - - - - - +   3802c9

        |   parsing routines  |

        + - - - - - - - - - - +   3802c9

        |     adjectives      |

        +---------------------+   6108c9

        |     dictionary      |

        +---------------------+   61fe00

Compiled with 7483 suppressed warnings

[Dannii Willis]

Okay, so that means the maximum diff would be 3646KB. Most of the time it would be considerably smaller. Ben knows more how Git works, so he might be able to estimate how much would be required, but 10MB to start with would surely get you several turns.

(I don't know why the memory map doesn't print things in the right order...)

[roody...@gmail.com]

Would it be possible to increase the buffer size on the included Hugo interpreter, too? I've run into instances where there isn't enough memory for one undo.

[Ori Avtalion]

On 12/30/2012 07:15 AM, Dannii Willis wrote:

(I don't know why the memory map doesn't print things in the right order...)

Inform6 bug?
I have no code to test this patch on :D
I assume someone here compiled more i6 files than I ever did (0), and can test.


diff --git a/tables.c b/tables.c
index 7715eb6..02597d1 100644
--- a/tables.c
+++ b/tables.c
@@ -1802,10 +1802,10 @@ printf("Readable|    grammar table    |\n");
 printf("memory  + - - - - - - - - - - +   %06lx\n",
   (long int) (Write_RAM_At+actions_at));
 printf("        |       actions       |\n");
-printf("        + - - - - - - - - - - +   %06lx\n", (long int) preactions_at);
+printf("        + - - - - - - - - - - +   %06lx\n", (long int) Write_RAM_At+preactions_at);
 printf("        |   parsing routines  |\n");
 printf("        + - - - - - - - - - - +   %06lx\n",
-                                          (long int) adjectives_offset);
+                                          (long int) Write_RAM_At+adjectives_offset);
 printf("        |     adjectives      |\n");
 printf("        +---------------------+   %06lx\n",
   (long int) dictionary_offset);

[Ben Cressey]

On Sun, Dec 30, 2012 at 12:42 PM, <roody...@gmail.com> wrote:

Would it be possible to increase the buffer size on the included Hugo interpreter, too? I've run into instances where there isn't enough memory for one undo.

OK, I've opened an issue for this:

https://code.google.com/p/garglk/issues/detail?id=198

Can you post a sample test case there, so I can tune the buffer size and validate that it helps?

[Ben Cressey]

On Sat, Dec 29, 2012 at 9:00 PM, Emily Short <ems...@mindspring.com> wrote:

I'm on OS X, so that's the easiest for me to test myself; Windows builds I'd have to ship off to my betatesters for analysis.  

OK, I'll prioritize getting the OS X build out in that case. I don't have either build environment ready to go at the moment (on account of entropy and some holiday upgrades) but I should be up and running in the next day or two.

[Andrew Plotkin]

On Sun, 30 Dec 2012, Ori Avtalion wrote:

> On 12/30/2012 07:15 AM, Dannii Willis wrote:
> (I don't know why the memory map doesn't print things in the
> right order...)
>
>
> Inform6 bug?

Yeah. Dannii already filed it -- we use the http://inform7.com/mantis site
for I6 bugs.

I managed to fix one of the complaints here without noticing the others. I
am going to drop the "parsing routines" and "adjectives" lines altogether,
because they're not used in Glulx.

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*

[Emily Short]

Awesome, thanks.

[Ben Cressey]

OK, here are the OS X builds:

https://dl.dropbox.com/u/2759298/gargoyle-2011.1-mac_undoSize_10MB.dmg

https://dl.dropbox.com/u/2759298/gargoyle-2011.1-mac_undoSize_5MB.dmg

https://dl.dropbox.com/u/2759298/gargoyle-2011.1-mac_undoSize_2MB.dmg

(The easiest way to use them is to just launch the app from the disk image.)

I did some quick sanity testing to confirm that undo works, and that a number of turns can be undone in succession. The 2 MB build can undo about 10 simple turns (going north repeatedly) so that's probably out in terms of robust support.

For validation I'd suggest a more targeted script that runs from startup through a few major state-changing events, then rewinds back to the first turn by way of undo.

--

You received this message because you are subscribed to the Google Groups "garglk-dev" group.

To view this discussion on the web visit https://groups.google.com/d/msg/garglk-dev/-/zSU6vjgjBykJ.

[Emily Short]

Sweet! Much appreciated. I'll check these out as soon as I get some time later.

[Emily Short]

So far it's looking as though even the 2MB is an effective improvement, but I want to spend some more time with this, and I keep not having a big enough chunk of continuous time to finish testing properly. But I hope to do so soon.

[Andrew Plotkin]

On Sat, 5 Jan 2013, Emily Short wrote:

> So far it's looking as though even the 2MB is an effective improvement, but
> I want to spend some more time with this, and I keep not having a big
> enough chunk of continuous time to finish testing properly. But I hope to
> do so soon.

I've played the beginning of CF (release 2) (up through the hostel and
cinema), using Mac Gargoyle with 2MB. I tried "undo" in several spots. It
is behaving correctly as far as I can tell.