Ascii and Glulx - a match made in ... hell?


Define unto me the abstract concepts oriented in a skyward fashion (or in layman’s terms: what’s up)?

So. Ascii and Glulx.

Through dumb luck (and science) and by bothering a fellow forum goer a whole lot I have discovered that my pretty effects don’t show and in fact become horrible monstrosities in other interpreters (though their choice of platform being devoid of soul and God may have something to do with it). Which sucks because I spent a lot of time on this stuff already.

So. Ascii in Glulx. What do you think?

Works fine in Glulxe, doesn’t really look too badly in GIT… looks godawful in Gargoyle.

What say you?

… after the beep.



Have you tried and made sure that your ASCII art is in fixed-width mode? That should make it at least consistent across interpreters. Somewhat.

yes, at all times.

it shows up SUPERAWESOME in my glulxe…

shows up (albeit a bit off, but functional) in git.

shows up crap in gargoyle (though zoom seems to handle it well so far, aside that they’ve got the window size to “super small” or something).

I mean, is ASCII art done in the IF world?
I’m told that it isn’t.

It’s done sometimes, but nothing too extravagant because - as you found out - it’s somewhat dependant on interpreters, window sizes, fonts… too many variables to guarantee quality.

It’s a bit more popular in the ZMachine, I guess, because in Glulxe you don’t need ASCII art per se; it’s easy to actually just include a picture and be done with it.

In fact, though this will seem odd, it may be easier to add your ASCII art as a fixed image rather than in-game text characters…

…but stay tuned, maybe someone else will actually have a solution to your problem, instead of an ugly workaround. :wink:

Well, a thought occurs.

You can include gargoyle, git and glulxe configuration files with your game. Have these configuration files force some settings - I’m thinking specifically of font and font size, naturally. When the player loads your game, if those files are in the same folder as the game, your configurations file will override the defaults. This may help you in getting a more uniform look across those specific terps.

What’s specifically the problem in Gargoyle?

/I mean, is ASCII art done in the IF world?
I’m told that it isn’t./

I’m told there is ASCII in art in Sam Barlow’s Her Story…
… which has somewhat exceeded the author’s IF roots, but still keeps a foot in it.

ASCII art in IF goes back to Zork I, but I think it’s kind of fallen out of fashion since then.

Infidel is another game that breaks in certain interpreters, because of the ASCII art heiro-pics.

Zork III’s Royal Puzzle breaks if you don’t have the interpreter set to a fixed-width font–but that’s because, back in the day, fixed-width fonts were the only fonts there were, and so those passages aren’t enclosed in a “fixed-width” tag or anything.

This is too bad. I had one idea to use ASCII art for a game map (a bit like roguelikes like ADOM’s overmaps). When using a Glk TextGrid it’s in principle supposed to render fixed width but we’ll have to see how that goes in practice in various interpreters.

Can you give examples of what you’re trying to print?

My experience is that ASCII art which uses actual ASCII comes out reliably in fixed-width fonts. If you try to use Unicode block-art characters, it’s a mixed bag.

Zork 3 (and a few other Infocom games) got an updated version for the Mac release, adding the fixed-width opcode. This was because Infocom’s Mac interpreter did support variable-width fonts.


This came up in another thread so I thought I’d create a test case.

source code:

This is what it looks like in the Mac IDE:

Everything works except that the fancy R takes up more than one letter space, so the right side of its box is misaligned.

When I try this in Lectrote, I get the same result.

Gargoyle can’t handle of the Unicode characters (most of them come out as question marks) but the ASCII part works correctly.


In Fabularium on Android, everything works except for a different alignment issue in the Unicode map:

1 Like

Did somebody say ASCII? Hold my coffee


Thanks for this test, I found it helpful! I gave it a try in dumb-frotz. Like gargoyle, the unicode rendered incorrectly but ascii looked great. Here is the output:

1 Like

Dumb-frotz will depend entirely on your terminal software. When I run the game file under CheapGlulxe (which is terminal-based with no curses library), it works fine on MacOS:

It has nothing to do with the interpreter, it’s how the Mac renders text.

(Although your screenshot looks like the interpreter is either not handling Unicode at all or not translating it properly to your terminal’s character set.)


@zarf I just compiled the source for cheapglk and pointed the glulxe makefile at it to build glulxe. When you say “CheapGlulxe” is that the same thing as what I just built? I ran the test again using my build and the results were the same as the dumb-frotz image I posted above, making me think it is down to a terminal behavior issue like you said (i am on Fedora 29).

I used the glulxe source from here:

As well as the cheapglk from here:

You can also load ASCII images from external files. This can be a nice option because then you can store the ASCII in native layout – you don’t have to lard a single unreadable run-on text strings with [line break] as you do when it is embedded.

"ASCII Art File View" by Jeremy Douglass
[based on "ASCII Art Test Case" by Andrew Plotkin.]

The file of Moon Image (owned by another project)  is called "moon".

The Kitchen is a room. "Examine a thing here for ASCII art."
The moonfile is in the Kitchen.

Instead of examining the moonfile:
	say fixed letter spacing;
	say "[text of the file of Moon Image]";
	say variable letter spacing;
	say "(Image from the Phoon utility, originally by Jef Poskanzer.)";

The corresponding file will need a required header line, and will probably be named with the .glkdata extension. If you import it as “(owned by another project)” then the owner identifier can be whatever you want (e.g. “phoon”).


* //phoon// moon
          .--'   o    .   `--.         
       .-'@  @@@@@@ O   .   . `-.      
     .' @@  @@@@@@@@   @@@@   .  `.    
    /     . @@@@@@@@  @@@@@@     . \   
   /@@  o    @@@@@@.   @@@@    O   @\  
  /@@@@                @@@@@@     @@@\ 
 . @@@@@   `.-./    . @@@@@@@@  .  @@ .
 | @@@@   --`-'  .      @@@@@@@       |
 |@ @@        `      o  @@@@@@ @@@@   |
 |      @@        o      @@   @@@@@@  |
 ` .  @       @@     ()   @@@  @@@@   '
  \     @@   @@@@        . @@   .  o / 
   \   @@@@  @@\  .           o     /  
    \ . @@     _\ /    .      .-.  /    
     `.    .    ()---        `-' .'     
       `-.    ./ |  .   o     .-'       
          `--./   .       .--'