I was reinspired to spruce up my WIP (and finally actually tackle some of the stuff Glimmr can do), and was dismayed to discover that both Gargoyle and Glulx have weird white space issues (again? I feel like I’ve had similar issues before).
Here’s Gargoyle:
There’s a white border around the entire thing, plus a weird gap where the status line doesn’t extend the length of the main window. (This gap is only present in some resizing, but the border is pretty constant.)
So I changed the main window color, hoping it would be less jarring. And now there’s a . . . not a border, but an L shaped piece, with extra main window color border beyond that. (Main window has been colored blue for clarity.)
Glulx has the white L, but not the extra border around everything.
What is going on? I assume the interps are adding some “padding” to make sure everything looks nice, which is fine, but what if I want control over that padding?
I think I can do without the left-hand border, which will make the white space there look more natural, but I would really like the bottom border to be at the bottom of the user’s screen. (The Photopia screenshot on the Gargoyle website doesn’t have this issue.)
Even just a “please make the padding this color” command would be workable.
The padding around the outside: This is a standard Gargoyle feature. To set your own margin or get rid of the margin entirely, copy the initialization file (.ini) into the same directory as your game file and then edit it to remove the margins. You can distribute the .ini with your game to ensure that players can experience the game the way you intended.
Bugs with the above: Make sure you’re running the very latest release version of Gargoyle. There was a bug with margins and background colors that was fixed…er, relatively recently, I think. This might be behind the L shape you’re seeing…?
The “notch” on the status bar: This is also an issue with Zoom and probably other interpreters as well. (It can be even uglier on Zoom because it occurs on both left and right.) The width of the background color is a function of the monotype font width, and if the match between the window width and the background hint isn’t exact, you’ll see an artifact. I haven’t tested it, but you might be able to fix this by affirmatively setting the background color (and perhaps also the font color) of the status window (using Glulx Status Window Control or some library hacking). This has the added benefit of allowing your game to look the same in all terps. If changing the background color of the status window doesn’t work, an email to Ben Cressey (Gargoyle) and Andrew Hunter (Zoom) might convince them to use the background color of a grid window to fill any gap left by measurement issues.
FYI: Flexible Windows incorporates a little hack that Ben provided for setting the color of the margin. I think you can read about it in some detail by scrolling through the source code.
I have no solutions to offer, of course, only a rant. My experience in the past, when bringing up issues around the appearance of the interpreter window, was pretty consistently that I got shot down by people saying, “That’s not something the author should want any control over!”
If an author is using the glimmr extensions (which I haven’t tried), why should they expect to be able to control the appearance of the terp window? Just sayin’…
The issue is compounded because I kind of suck at graphic design anyway, so basically all my patience is gone by the time I am double-checking the compilation to “just make sure it works” before moving on to the next bit. (Oh, god, sprites.) And since I don’t have a background in what’s happening onscreen, I just want to open a Photoshop-like editor, throw together the screen, toss in some sprites and a .gif animation or two, toss on a toggle for the players who don’t like pretty colors, add a splash and menu screen, push the “compatible for all interps” button, and go watch a movie.
The tools are there (except for .gifs, I think), but I have trouble using them, and then the interp layer makes everything more complicated. For instance, in the inventory window in Gargoyle, all the text is at the bottom of the window. In Glulxe, it’s at the top. I don’t mean to be obsessive, but it looks wrong to me at the bottom, and there’s no easy way to know that a particular interp will do that, or how to fix it, without Serious Effort. I’m sure there’s a way, but it seems like I’m better off picking one interp and wrestling it.
One of the few pages on Glulxe gives instructions for setting up a config file. There’s two options given for borders, neither of which touches my issue at all.
I don’t know. I know I seem extra petulant, but it’s like a perfect storm of ignorance, minimal skill sets, lack of instructions, and near-opaque machinery. And it’s exhausting when your attempts to make something look better only make it look incredibly amateurish. And then the interps make it amateurish with gaps.
Okay. Tantrum over. Let’s fix this thing.
I downloaded a fresh copy of Gargoyle from the Google code page onto a computer that’s never had it before, so I don’t think that’s the problem.
The status window color is customized above; I have the same issue if I change the text color. I’ll email folks.
I’ll take a look at the .ini files. The potential downside I see here is that I would like to allow the player to turn on/off the extra windows for people who like to play traditionally; it sounds like this means giving explicit set-up directions (or releasing two versions).
The margin hint is great - I’ll go see what I can do with that. Thanks!
IIRC Git 1.2.8 was in the latest release, so I think you’re up to date.
The padding is controlled by the last background color hint sent to a textbuffer window. Once you’re done opening windows, just set another stylehint like so:
To reset the padding color:
(- glk_stylehint_set(wintype_textbuffer, 0, stylehint_backcolor, 16777215);-)
By Glulx do you mean WinGlulxe or WinGit? If the L-shape problem appears in both winglk and garglk, it is likely an issue with your code. You may be splitting off a window and not assigning the full width / height of the parent to the new child.
Offhand I would guess that you are getting the window dimensions from glk_window_get_size, and then doing a fixed window split in the amount of the height or width returned. This will not work in the general case for text buffers, since those measurements are based on characters rather than pixels; it’s better to do a 100% proportional split instead.
Erik covered the status line issue pretty well. If his suggestion doesn’t work to correct it, let me know and I will get a real fix into Gargoyle.
Glk offers no guarantees on how text will flow in a text buffer. In Gargoyle, new text enters at the bottom and scrolls up. In Windows Glk, text enters at the top and scrolls down. The reason Gargoyle does it like that is to make sure the input line is always on the bottom. Obviously if you have a buffer that doesn’t need line input, this is not a cardinal virtue. But it’s not wrong in the sense that it deviates from the spec.
If you need precision, use a text grid window, count spaces and move the cursor as needed. Or, use a text buffer, measure the height, and fill empty lines with ‘\n’ so there’s something on every line. That way the output should look similar under most Glk libraries.
This is a clever suggestion and should work in most Glk implementations. I think that it will not work correctly in Zoom, unfortunately, because Zoom departs from the spec by measuring text-buffer windows in pixels instead of characters.
I’ll give it a whirl. I didn’t mean it’s inherently “wrong” to start at the bottom - just that there’s a big difference to the eye, and visually, it “looks” off to me. In the main window, that difference goes away eventually; in text buffers it won’t. It’s not a judgment on any one interp or implementation choice - just general unhappiness that it’s quite so much work to standardize the playing experience.
Thanks for your help. Somehow I managed to put together a file without the L-space, but honestly I can’t figure out how. (I switched computers, and a few interim experiments were lost.) The gap shows up on occasion, because I haven’t done anything with it, but the white space is gone.
Well, it is a bit unnatural, isn’t it? Text flows in from the top in books and on the web–twentieth century earth’s two major text-based UIs. I have the same feeling about flowing text from the bottom that you do–it’s is fine in the main window where it works, as Ben mentioned, to keep the prompt at the bottom of the screen. But if you have text windows without prompts, they just look goofy.
You might test whether the player is using Zoom to avoid the massive problem that would result from using this method in that terp (hundreds of blank lines, driving the content way back into the scroll buffer). You could measure the width of the buffer window first; if it comes back greater than 200 or so, it’s a good bet that the window is measured in pixels rather than characters. You’d then follow Ben’s solution only for windows that are measured in characters.
Does Zoom run glulx games? I think Glimmr and company are exclusively glulx, and I’ve only ever used Glulxe and Git (on various incarnations of Windows).
I can handle testing on two interpreters (sort of), but much beyond that and I start wondering if it’s okay just to ask people to use one of the ones that I worked on. (I remember at least one person complaining bitterly about such a request from one of the comp games, so I’m thinking authors are expected to optimize across every major interpreter.)
Do I need to add Quixe to my list even if I’m not planning on doing on-line play?
There are multiple levels of terminology (unfortunately confusing) going on here. Glulx is the name of the virtual machine, equivalent to the Z-machine. Glulxe and Git are the names of the two major interpreters. But there’s another level: The various Glk libraries are used as the basis for what you might think of as interpreter “viewers”. So, Zoom can run either glulxe or git using the CocoaGlk library. Gargoyle runs both glulxe and git using the GarGlk library. And Windows Glulxe and Windows Git are two different executables, each running one of the two (both using the WinGlk library). So, you aren’t actually testing on interpreters other than glulxe and git usually, but on different Glk libraries or “viewer” executables…
I don’t think it would be wise to ignore Zoom completely in your testing. It’s still probably the most-used OS X interpreter, and it’s the interpreter that’s built into the OS X Inform IDE. I believe it’s also a popular *nix interpreter.
For Quixe, console interpreters, etc., I’d just test a gestalt (graphics, for example, if your final game will include graphic windows; see Glulx Entry Points) and, if the terp fails the test, print a message that your game is not supported and quit.
Oh, crap. I thought I had all this sorted out. You’re right - I totally missed a layer. Jesus, that’s confusing. And, sure enough, Zoom’s individual page on the ifarchive mentions that it has support for glulx games, but it’s not listed under glulx interpreters. So what gets listed under glulx interpreters? Solely glulx?
