If you use Flexible Windows by Jon Ingold you will definitely want this update - it improves performance by 30 times. You shouldn’t need to change your code, however it does make a slightly incompatible change: g-windows are now a kind of container. So be careful not to just repeat through all containers.
Get it here: https://raw.github.com/i7/extensions/master/Jon%20Ingold/Flexible%20Windows.i7x
Lastly I have a new extension, which I wrote for Counterfeit Monkey: Ultra Undo. Counterfeit Monkey has problems with interpreters like Gargoyle because it is too big for the undo function to work. Ultra Undo will keep undo working by using external files if needed. Counterfeit Monkey is the only story I’ve ever heard of with this problem, but if you find yourself writing something of the same size, you’ll want to give this extension a try.
Get it here: https://raw.github.com/i7/extensions/master/Dannii%20Willis/Ultra%20Undo.i7x
There are unfortunately a lot of slow parts of Inform. If we’re lucky we can rewrite the code or work around it. If we’re unlucky we’ll need to wait until the Inform 7 source code is eventually made public.
I put your new Flex Windows in my Leadlight port. It compiled fine. In the Zoom IDE, it runs about the same as before, but I can’t really check for hyperacceleration in the compiled form in Gargoyle, where the game was already way fast. Maybe I could check the compiled version running in Zoom. But this game probably isn’t pushing Flex Windows very hard anyway.
Good luck on that! It takes multi-years just for a new release to come out. I can’t imagine a full source release being any time soon. Nice extensions, though. The benchmarking one actually gave me some good insight into I6.
I’ve written a new extension: xorshift. It replaces Inform’s random number generator with one that is consistent across all interpreters and computers. It probably won’t be useful for very many people, but we’ll be using it in Kerkerkruip.
Cool, thanks! So this could be combined with Procedural Randomness to set up something like generating a random universe from a keyword that would be the same across all interpreters and computers – or are you telling me that Procedural Randomness doesn’t need xorshift for that to happen?
I don’t think you’d need Procedural Randomness at all for that. Just calculate a number from your keyword (with some sort of hash function) or object (by casting it to an integer), then set the xorshift seed to that and use [purely at random] (or “a random X”).
Well the point wouldn’t be just to generate one consistently random number – you’d want to generate the number from your object, and then do something like add a longitude to that number and use that number as the seed so every time you went back to the same longitude you could psuedo-randomly generate the same stuff again (without needing to store what you’d generated, because you could just regenerate it). Procedural Randomness is designed for stuff like that – I think just reseeding xorshift to do that might require rebuilding a lot of the functionality of Procedural Randomness. Or maybe not.
Part of my question here is, does Procedural Randomness also behave consistently across interpreters and computers?
Interesting. I looked at the source code for Procedural Randomness and it seems to implement its own pseudo-random number generator. So yes, I expect it would behave consistently (although not between Z-Machine and Glulx, because of the word size difference).
I think my extension might work better for that matt. Procedural Randomness’s strengths are with the say phrases - you set the seed every time you enter a room and then the random descriptions get pinned for that room. In your case it sounds like you just need a lot of random numbers. xorshift will be easier to use for that, and its random numbers will probably be of a higher quality. If you did want the same room specific stuff you could simply seed it with the room as well.