I’ve gotten a couple of questions about games not running in Quixe. I just ran through all of the Glulx games – just a couple moves in each – to test them.
Results: All work except The Blind House (goes into a spin-loop after the first conversation menu) and Following A Star (exits immediately with an error).
I haven’t tried to analyze either game. But I also tried all the games in Glulxe with GlkTerm. This is a terminal-window display library which, like Quixe, has no graphics capability. I got the same results – all the games worked except those two, which had the same errors.
This leads me to believe that both games are failing to allow for the possibility of graphic windows not being available. That is, these are either game bugs or extension bugs, not interpreter bugs. (Blind House uses Flexible Windows 9; Star is an I6 game and I don’t know what the code is like.)
Both games are trying to open a graphics window at the crash points you mention, so that’s the issue. Both of them should probably be taken off the play-online list—the performance might affect voting.
Blind House is screwy in Gargoyle (newest version) on the Mac–nothing prints at the beginning of the game (after the intro screen), but you can eventually get to the point where you can enter line input, after which text prints normally. I wonder if output is going into an alternate stream or something?
Played around a bit more and found that you can get the opening text to appear in Blind House by changing the window size. Zoom sends an arrange event independent of the player (WinGlulxe/WinGit may do the same, it’s been a few months since I was looking at this stuff) when the first input loop runs in a given window configuration. Gargoyle does not. So it’s probably the case that the initial text and status line text in Blind House require an arrange event to print. I’m not sure why, perhaps something to do with the char input loops that start the game. In any case, this is what I’m guessing is behind the need to send an arrange event in Gargoyle (i.e., resize the window) before the text becomes visible.
The initial text in Blind House did appear, on both interpreters I tested. The problem happened after the first dialogue interaction.
The crash with Quixe is due to the game opening a graphics window immediately after the first dialogue response. The other issue, which really doesn’t belong in this thread (but hey), is that on Gargoyle (most recent Mac version), you have to resize the window to get text to appear; I suspect that this is due to odd logic involving arrange events, but may be due to something else. Zoom and some other interpreters send bogus arrange events, which might explain why the text displays on those interpreters and not on Gargoyle. Or it might not…
Right, sorry, I see what you’re saying.
It must be more complicated than that, though. I can get as far as the dialogue menu in CheapGlk, which never sends arrange events at all.
Yes, if CheapGlk doesn’t send arrange events then the problem must lie elsewhere… Ben, have you tried this game in Gargoyle?
I’ve now removed the “Play online” links from those two games. I’ve also re-jiggered it so the web games now have online play links.
Only as far as replicating your experience.
If you open the Help menu before starting the game, then everything seems to work perfectly. In fact if you press any key other than space at the first menu, to trigger a second iteration of the loop, then everything is fine.
I don’t know what to make of that. I will look into it more this evening.
It appears that after the menu is printed, glk_set_window is called with a null parameter. This sets the current output stream to null, and causes all further glk_put_char calls to silently do nothing until the next glk_set_window call.
Doesn’t really seem like a library issue, I guess.
Hard to say at this point. Hopefully post-Comp we can work with the author and see what the code is doing.