Alternative to Frotz for IOS

+1 for Grafio for mapping on iOS. Excellent companion to iFrotz and well worth the price, IMHO.

iFrotz has a built-in notepad, but it’s text-only. And I lifted the idea for my Dreamhold/etc interpreter.

(You probably knew that, but I point it out just in case.)

Depends.

SuperGlus games (spanish… er… inform mod?) have a serious problem that makes them unplayable in proper interpreters - I had to specifically ask, plead and cajole David Kinder for a version of Git/Glulxe that would play them, by bypassing some strict memory checking I believe, and I based my request merely on the number of games that already exist.

EVERY glulx game with an accented character in a room name WILL FREEZE on iFrotz. It’s a bit obscure, this one, but there you go.

Other than that, there’s no guarantee the errors you’re experiencing have anything to do with the errors I’ve reported already. Your best bet is always to report new issues.

Superglús is not an Inform mod. It targets glulx and (as far as I know) uses features of the machine not implemented on some interpreters, that’s it.
ifwiki.org/index.php/Superglus
https://intfiction.org/t/winglulxe-vs-wingit/4488/1
foro.caad.es/viewtopic.php?f=6&t=2079

Ok, thanks for the correction.

[rant]I’m not entirely sure how feasible it is, if that’s what it’s really doing, to use features not implemented in the main, most widely used interpreter, especially features that make the game broken when the interpreter updates and then the interpreter needs a special, less strict version to allow for these games not to crash on running…

…but whatever.[/rant]

Added rant tags because I was talking without proper knowledge of the topic - through the proverbial arsehole, pretty much.

EDIT - I’m possibly being a little harsh - so the Glulx system used in SuperGlus is not descended from Inform, from what I see, but sort of piggybacks on Glulx. Therefore it’d be normal for a few mishaps here and there.

It might make more sense, methinks, for SuperGlus games to have their own interpreter. Do they?

Superglús is an alternate compiler, not a variation of Inform.

The compatibility problem is that early versions use a Glulx feature which was not clearly specified in the spec, and not properly implemented in my interpreter. (That is, the spec contradicted itself, and what I implemented was broken in some cases that the spec said should work. Git didn’t implement this feature at all.)

I have now deprecated this whole feature, and the current version of Superglús doesn’t try to use it.

eblong.com/zarf/glulx/about-locals.html

Fantastic.

Hi,

As Zarf says, Superglus…

a) Is not an Inform mod but a completely separated compiler that uses Glulx as target (it generates Glulx assembler that is later compiled by Simon Stapleton’s Gluxa assembler)
2) Early version were using a feature that, though at the time those versions were built was supported by most interpreters, later become not supported by some new interpreters, specially by Git, but it seems that now it’s also not supported by iFrotz. That feature is now even “deprecated” but that doesn’t change the fact old games were using it.

The “4 byte vars” error become common when running Superglus games since Git become the default glulx interpreter for the widely used interpreter pack Gargoyle. At that point, as it seemed not easy to make all interpreters support that feature, and even the feature itself become deprecated in the specifications, I (co-author of Superglus) decided to move this way:

  1. I made a new build of Superlgus that was not using that feature (so new Superglus games wouldn’t be affected)
  2. Ask mantainers of Gargoyle pack make Glulxe the default interpreter for files with .blb extension (most glulx games made with inform use .gblorb, while Superglus uses .blb). Ben Cressey gently accepted that change and newest versions of Gargoyle play old Superglus games properly (as it launches Glulxe instead of Git).

Apparently that made everyting work fine for a long time, but now it seems iFrotz made that issue come back.

Honestly, I cannot do too much to solve it:

  • I cannot get old games and recompile them (what would fix the problem) without author’s permission, and many authors are not active anymore, source code is not avaliable, or if avaliable license does not allow recompiling or just there is no license detailing whether we can rebuild them or not.

  • I doubt any new interpreter, like iFrotz, do ever support a deprecated feature (if the feature is supported, the games run properly).

So in the end I’m afraid the problem Peter faced when running some Superglus games in iFrotz is hard to fix. If other interpreter authors that were previously supporting that feature start removing support from their interpreters cause now it’s deprecated, the situation can only become worse (though I don’t actually know if that would happen or has happened).

Well, the author is aware of the situation. I very much doubt he’ll trouble about it much, because he’s got a lot on his plate without this problem which affects only a minority of games (and non-english games to boot. And please don’t shoot me down on any pretense of political correctness). But he knows about it, so it’s possible that at some stage in the future he might address it.

And, I’ll have to correct you:

My test subject: Crisis Demográfica en la Aldea de los Pitufos (Demographic Crisis in the Smurf Village)

Reason: because the name is so ridiculously long and the theme seems to be so thought provoking and, on a few levels, so deliciously wrong, it kinda stuck and I always remember it exists.

Git: “Short local variables are not supported, use Glulxe”

Glulxe: “Glulxe fatal error: Memory write to read-only address (0)”.

To be fair, the Glulxe problem only appeared after a relatively recent Glulxe update. I explained this problem to the maintainer who very, very, very kindly compiled a version which I seem to identify, in my hard drive, as “Glulxe (No memory checks)”. That one works a charm.

Okay, that is a different problem. No relation to the local-variables thing. I was unaware of that one until now.

That error message is clear: the game is writing to memory address zero. This has always been illegal but Glulxe didn’t check it (by default) until version 0.5.0.

To compile a version of Glulxe without that memory check, delete the line “#define VERIFY_MEMORY_ACCESS” in glulxe.h.

Wo-hooo! I was relevant! :smiley:

Yes, that was a bug on Superglus code by that time that made some games write to Glulx ROM, and yes it was detected later and fixed, but games compiled with that bug still have it.

The bug was not a problem cause address 0 just has the Glulx header, but in the end writing to ROM is incorrect. I detected that at the same time I detected the non 4-byte vars issue, just because Git did ROM write check, while neither Glulxe, nor Zag nor other interpreters at that time did memory check. Now it seems Glulxe makes ROM check by default so those games fail too with Glulxe.

Again, nothing I can do without rebuilding the game, that I cannot do.

Note: the bug originally appeard due to Gluxa’s limited error reporting. At that time, Glulxa replaced any unknown identifier with zero, instead of issuing an error message and stopping assembling. There was a typo in the assembler code, and instead of storing an auxiliary value in the expected place, it was stored at address 0. I updated Glulxa so at least that kind of errors are reported, but too late to avoid this bug.

Yeah, I know it’s a problem when an interpreter bug persists this long.

I could add a Glulxe compile-time option that explicitly permits a zero-write to occur (with no effect). That would be safer than turning off VERIFY_MEMORY_ACCESS. Do you know if it’s always the same VM opcode that does the zero-write?

I’m afraid my memories are weak… I detected that bug back in 2009…

I recall that writing to address zero was the problem (not ROM in general), and that the cause was typo + lack of error reporting in Glulxa.

But I cannot recall if there were only a typo, or several. I cannot even recall which label it was, so I cannot just check old sources to see if it was used one or more times and which opcodes were used. On the ther hand, I would bet that if you allow the “copy” opcode write to address zero it will work fine, so maybe you can add a compile-tiem option that permits that and see what happens.

Probably the best way to check it is running one of the affected games (dl.dropbox.com/u/2407979/OBRAS/pitufos.zip) and see which opcode is being executed when a ROM write action happens.

Note: I have just made a “diff” of the oldest source code I have versus the new one, and I’m afraid that are so many differences that it would take me hours to check them all one by one to try to make my memories come back. If needed, I can do it.

Don’t worry about checking your source code. I’ll try some of the affected games and report back.

Not until next week, though.

Ok, great, thanks!

Frotz does play King now, if you’re still looking. The problem now becomes Counterfeit Monkey

CM is problematic on any non-desktop terp. Craig is aware of it, as well as other minor outstanding issues in a couple of games, but if you want to play CM at all it’s best to play it on your desktop.

Currently, iFrotz is at the stage where it doesn’t need alternatives, one should hope. Glulx support is now solid and reliable.