WinGlulxe textgrids - they're not monospaced?

I’m testing something in WinGlulxe.

It seems that by default it doesn’t present textgrid window content in a monospaced font, but in a variable spaced one.

I don’t think an interpreter should be allowed to use anything but monospaced fonts in a textgrid. Otherwise it’s not a grid and you can’t program anything gridlike with it. At least in Glulx? I don’t know enough about the Z-machine equivalents.

Does anyone have reasons to disagree with this?


Although I’m not a programmer in the awesome sense that most of you are, I usually subscribe to the theory that downright disallowing something is never a good idea; someone will want to use the non-standard feature, however strange that may seem.

Maybe if the default was a monospaced font instead? Would that be better? Is this even specified in the ZMachine specs floating around?

Text grids definitely should be a mono-spaced font. However, some Windows fonts are more mono-spaced than others … Can you provide an explanation of what you’re doing and seeing? A screenshot would help too.

This might be a stupid “is it plugged in?” type of question, but is the code in Inform actually tagged [fixed letter spacing]?

Text grids should be monospace regardless of whether [fixed letter spacing] is used.

Unless you changed the fonts the default should be monospaced already.

Hm, I’m mildly concerned I could have changed the font by accident. I should explain the whole context.

My main computer is a new Mac but I’ve got this 1998 PC running Windows XP that I use to see how games are running on PCs. Now with WinGlulxe, I remember there was a moment last year where I started poking at options, then thought ‘How do I get this back to its defaults?’ And being a Windows machine and not my home turf, I didn’t know how to erase the preferences. I tried reinstalling the whole program but that didn’t seem to change any of the settings. So I wasn’t sure if that meant I hadn’t actually messed with them, or just that the preferences survived the reinstall.

In any case, could one of you kind folk tell me how to proceed to reset WinGlulxe’s options back to the default state? Once I have done that I will report back.


Funny, we were talking about something similar in another thread. The preferences are probably somewhere in AppData, rather than in the program folder. It appears that what happened to you, i.e. have the interpreter remember the settings between uninstallations by having the configuration data stored elsewhere, is Very Much A Good Thing In Computing.

(sarcasm aside, I do understand the need for it, it’s been explained quite well. But it’s kind of interesting to see this specific instance come up)

EDIT - Windows XP? I have no idea if this AppData thing is even relevant, then. Apologies if not.

Look for “Glk Applications” in the registry (regedit). You can probably delete the whole section.

Oh wow, in the registry? Seriously, as much as I love these interpreters and the dedication of the people behind them, does it have to go that far just to store a few settings? I guess I can wave the portability of my settings in my backed-up collection goodbye. Shame, I’ve got my font and colours just as I like them, and setting up all the styles in Glulxe and Git is a bit of a bore…

OK, the regedit thing worked, and WinGlulxe went back to defaults, and it wasn’t monospaced by default. So that’s ended well. Specifically, everything lined up in the status window where I expected it to.

Unfortunately it still turned out that both WinGlulxe and WinGit aren’t producing an ascii map in a separate textgrid window correctly, in spite of it being a monospaced textgrid window. The problem isn’t a lack of monospacing this time, but the window seems to be only half the width in characters that I ask for via flexible windows. Therefore, each row of the map prints partly onto the next line, throwing out all alignment. I even checked in Filfre, which shows the same issue.

This doesn’t happen in Gargoyle or Zoom; the ascii map works in those. (I know Zoom’s old and super buggy now, but back when I originally coded this bit, I didn’t know that, and made sure it was OK in Zoom.)

So… I don’t know, some problem between Flexible Windows or textgrid windows and certain interpreters? This is 6G60.


Bah. I was about to make a post telling you to ignore the rubbish about registry editing (hardly ever a good idea). Since Windows Glk should not let you make the text grid window non-monospaced, I would have liked to figure out what font you were using and why that wasn’t coming out right, so that we could have seen if there was a bug in Windows Glk and fixed it properly if there was. Now we’ll never know.

There’s an old saying that, just because code works on one machine, that doesn’t mean it’s right. At a guess, the most likely reason is a bug in the game logic somewhere that just happens to give what you want in Zoom and Gargoyle, but not elsewhere. But you’ll have to post an example or some code or (better) the actual game exhibiting the problem for any proper analysis.

Au contraire! Now that I understand that that 2nd little ‘A’ button is for changing the font of textgrid windows, I can easily make them non-monospaced on my old PC. Going down the font list which appears, ENCTICON, Terminal, and any of the fonts whose names are preceded by WST_ all give a variable spaced result for me in Glulxe on Windows XP.

I have put together a test case which demonstrates the burgeoning problems.

Basically, I use Mark Tilford’s Automap. But instead of having the map in the status window itself, I scan over its data, translate it very slightly, and reprint it in a new textgrid window my own to the right of the main window.

The first problem is that it seems the first line of the map printout, which is actually not map data but the legend, including, ‘U = You’ appears considerably to the right of where I expect it to appear in some interpreters (Glulxe, Git, Filfre) but not in others (Gargoyle, Zoom). But then the rest of the map comes out the same, so yes, all interpreters are responding correctly to Flexible Windows’ call that the window be 33 characters wide.

The second problem is with my reprinted map in my new window - I have great trouble getting it to line up in general.

In the real game, I got it lining up in just 2 interpreters. In this demo game, now that I’m using someone else’s map, it’s not lining up in any again (but I’ve retained the height/width and reserve values from the real game in this demo). I either don’t understand the exact relationship between the reserved width and height and the values I need to use as I repeat through the map, or there’s probably some bug or issue I’ve just never understood.

So my dream is for the map to print out all lined-up and correct in any interpreter, and that the legend does too.

This is a 6G60 project. In the download, there’s the compiled test case, the two extensions it uses ((a copy of Automap that I’ve hacked slightly (I think mostly I moved bits of it to other places, rather than that I rewrote any routines) and a vanilla copy of Flexible Windows)) and the source of the test case.

Thanks if anyone works this out. I know it’s a very fiddly one.

ascii (567 KB)

Okay, that’s interesting. I don’t know where the ENCTICON or WST_ fonts have come from, but Terminal is a mono-spaced bitmap font that has been in Windows since the Dawn of Time. There seems to be some problem with it being substituted for a non-mono-spaced font by Windows. I suspect that the simplest solution is to disallow those old bitmap fonts - they’re all horrible anyway.

What font are you now using as the mono-spaced font with Windows Glulxe, then?

I will have a look when I can, but probably not for a few days.

Also, what do you actually expect to see? (That is, how about a screenshot of the automap looking as you think it should.)

Is it correct to say that your problem now is entirely about the width of the right-hand (textgrid) window?

It’s correct that I’m no longer talking about monospacing issues in WinGlulxe.

My sole problem is that I cannot get an interpolated ascii map to print out correctly, consistently, in the right textgrid window, depending on interpreter. Often, lines go over by a character, or many, or just don’t line up.

I’ve simplified the test case and now it’s clear and demonstrable, so please use the new attached files instead of the first lot. The new bundle has:

  • the compiled demo
  • the source code
  • hacked automap
  • vanilla flexible windows
  • gargoyle outcome screenshot
  • glulxe outcome screenshot

Run this in Gargoyle and walk about the full extent of the map, and you’ll see it looks fine.

Run it in Glulxe and after you’ve walked the full extent of the map, the map warps, though this only happens after you’ve travelled a certain horizontal distance.

ascii (1.26 MB)

On Windows 7 here I see something slightly different: the display is wrong when the game first starts, but doing anything that redraws the display, such as moving east, or maximizing and then un-maximizing the window, sorts it out and it looks right.

However, if I fire up a Windows XP virtual machine, I see exactly the same problems as you do. Most odd. I will investigate.

(By the way, even on Windows XP you ought to have at least Lucida Console as a better mono-spaced font. It won’t solve the problem, but Courier looks really horrible.)

Okay, it took me a little while to spot the catch here - that map window of yours isn’t a text grid window.

The textmap-window is a text-buffer g-window. So, it’s really a text buffer window, which explains why it’s sometimes big enough for the map, and sometimes not. As the Glk specification says:

Changing the source code to actually use a text-grid fixes this, except for one oddity: when the game first starts the map is not printed correctly, although after the first turn it is fine. I can’t see why this is but I will dig further.

Thanks David. Urgh, I made a whole topic about textgrid windows and I wasn’t even using one, even though I thought I was!

You know, that business where it misprints on the first turn, I’ve always been aware of that, too. My workaround is just to close, reopen and redraw on the first turn.

Anyway I’ll go apply my learnings to the real project now and see if it all comes good.

Addition: Yes, it now prints out fine in Gargoyle and Glulxe and Git.