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 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…
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.