Banner - Inform Glux/Glk for Dunces. Banner includes a dunce cap and the three, say no evil, hear no evil, see no evil monkeys.

Monkey wearing dunce cap, holding paper and pencil.
  1. 6. Alright, maybe I'll try this thing. How do I get started?

    1. a. Other Glulx/Glk References & Library Add-Ons:

      infglk Wrapper Reference - Attached to this guide is a summary of Glk functions as they appear wrapped in infglk.h. Covered are their:   purposes, arguments, and return values. So essentially, it is a brief "reference manual" to all Glk functions.

      Interpreter & Color Charts - Two charts are also attached to this guide. A chart of interpreters, showing the Glk capabilities each currently supports. And a color chart with their corresponding hexadecimal notations.

      unglklib I have also written a demo Glulx Inform multimedia game, "Just a Dream," that comes with an easy add-on Glk library for those who want to get "up and running" with Glk quickly. Also included is "briefglk," A Brief Overview of Glk for the Inform Programmer, with some examples from unglklib, and "Dream's" source code. "Just a Dream" also functions as an interpreter "tester," because the score is a test of what Glk capabilities (except the ability to play MODs) the player's interpreter supports.
      3/2009 - "Vistas," a demo of glk screen transtitions has also been added.

      dunno-bp.h and phtalk-bp.h are dunno.h and phtalkoo.h altered for Glulx Inform (the first altered by Zarf, the second by me). Dunno by Neil Cerutti apes the Infocom response "I don't know the word ____." Phtalk by David Glasser simulates Adam Cadre's menu system from Photopia.

      Roger Firth's Just Enough Glulx provides a header file for some basic Glk functions.

      The Game Author's Guide to Glulx Inform - Andrew Plotkin's guide covers all the new routines added to Inform, including Glk entry points, but it does not really detail Glk.

      Gull - Adam Cadre's guide focuses on how to actually use Glk to write multimedia Glulx Inform games. Several excellent demo games with source code are included.

      Glk API Specifications - Andrew Plotkin's Glk specifications are not a users' manual. They are designed for interpreter C-language programmers (remember, Glk is an API for interpreters) -- so great deal of information is not pertinent to Informers. However, a full explanation of window trees is given.

      Note that the following section about iblorb has not been updated. Evidentially the Window Glulxe interpreter now supports combining a separate game file (.ulx) with a separate blorb archive (.blb). However, I am not aware that any other interpreter currently supports that, so the below remains as is.

    2. Using iblorb - Iblorb is a Dos/Windows blorb file maker written by L. Ross Raszewski. It packs graphic images and sound files into an archive file. Currently, Glulxe does not support having a blorb resource file separate from the game file. So the game file is also packed into the archive. While this done, your Inform source code (.inf) is also complied.

      The file contains four executables:  Front End (the users' front end) - front.exe, Bres.exe - the blorb control block creator which also calls the Inform compiler, Blc.exe - the blorb file packer, and Bpal.exe - a blorb palette manager. However, you only need to run front end, the rest is done for you.


      1. If you are using Windows, open a Dos window or exit to the Dos prompt.

      2. Create a resource file with the same name as your game and the extension of .res -- mygame.res. This will list the pictures and sounds you want to use in your game. For all but the source code, each item is preceeded by a bres identifier:  CODE, PICTURE, or SOUND. The next word is the Inform constant that you will use in your source code to refer to that particular image or sound. Last is the path to each item.

        Identifier Constant Path
        CODE drive:\path\mygame.ulx
        PICTURE Mypic drive:\path\mypic.jpg
        SOUND Mysnd drive:\path\mysound.mod
        Use the extension, .ulx, for the source code (not .inf), even though it hasn't been compiled yet. You may also put on the last line HIGHCOLOR to include directions for a 16-bit palette, or TRUECOLOR for 32-bit.

      3. Create a file called infb.rc, telling Front End the name of the inform compiler you are using and the path to the Bres executable. This works best though if you unzip all iblorb's executables into the same directory as your source code and compiler. If you do put them in the same directory, you can drop the last line.
        INFORM informbp -G     or     informg
        BRES drive:\path\bres  (no extension)
        The g switch tells the bi-platform compiler to generate a Glulx Inform g-machine game file, not an Inform z-machine game file.

      4. Now put this line in your source code: #include "mygame.bli" (this is created by Bres, telling Blc which blorb to combine with the source code).

      5. Run front end by entering:  front mygame mygame.inf mygame.ulx. The first argument is the resource file (.res) without the extension. Viola! Front end complies your source code (calling the Inform compiler) and creates the blorb file all at the same time. The new file is called mygame.blb and can be loaded into a Glulxe interpreter.

    3. Necessary Programs & Files:

      Inform compiler Bi-platform Glulx Inform compiler
      (or single platform Glulx compiler)
      Inform library Bi-platform Glulx Inform library
      Inform interpreter Glulxe interpreter
      Glk library

      Just as you need an certain platform-specific files to write a regular Inform game -- you need the same thing to write Glulx Inform game. You also need two additional files:   the wrapper include file, infglk.h, and a Glk library for your platform. Since Glk is a portable API, it is separate. But, luckily, most interpreters come bundled with it.

      All can be found at . You can also find some at Zarf's Glulx page.

  2. Oh, one last question. Why do Glulx and Glk have such funny names?

    Zarf moves in mysterious ways. A banana skin.

    My Reasons for Not Continuing Support

    These pages were in a middle of a rewrite (2001) when I stopped support. Parts One & Four have been rewritten; Parts Two & Three Contain some factual errors -- mainly about styles. (Check with Brief Glk for more accurate presentation.) But I am leaving this tutorial up to help anyone it might help. 3/2009 - I think I have fixed most of the errors, if not please let me know.

    While writing " Carma, " I discovered that Glulx is not truly cross platform compatible. And, as far as I know, the various platform conflicts have never been resolved, ergo my withdrawal of support. Glulx seems to be interpreter-writer friendly and game-writer non-friendly. My memory of the conflicts is foggy now (and I never fully understood the "interpreter" details), but to summarize:

    • Windows/Linux - Inconsistencies in how game code was interpreted between the Windows interpreter and the Linux interpreter. This cropped up in two main areas, screen draws and the glk entry point, HandleGlkEvent. For me this meant that when I developed a game in Windows that worked, I had to tweak it like crazy to also get it to work with the Linux terp.
    • Linux - The Linux interpreter lacked code (that was supposed to be in the interpreter) to correctly draw certain types of jpegs. So two people wrote patches to make the Linux terp work with "Carma" and its intensive graphics approach. (The patches are at the archive.)
    • Linux - Ditto with sound files, patches had to created to handle "Carma's" sounds/music.
    • Windows/Mac - Sound files created under Windows, for some reason -- something to do with bit signing -- do not work with the Mac. Or, to be specific, do not work with QuickTime, the Mac terp's sound handler. This was the major platform incompatibility.
    • Windows/Mac - Ditto with graphic files, QuickTime could not do the "animations" that I had developed under Windows and that also ran fine with Linux. Although this was not a file incompatibility, it amounted to the same thing -- "Carma" would not run well on the Mac.

    I complained about the above incompatibilities and asked for graphic and sound file standardization, got patted on the head, and basically ignored (I hate that). For instance, the argument regarding the Windows/Linux code implementation differences seemed to be, "If I had written the code right in the first place then it would have worked with both." In other words, my code was buggy, not the interpreters. However, there is a big flaw with that argument -- there is not enough Glulx documentation and/or example source code to know when a specific coding approach is right or not (especially when trying something tricky)! Also, personally, I do not believe there should be that big a difference in how each interpreter interpretes code from one platform to another.

    I want to say that I think Window's Glulxe works just great thanks to David Kinder. But be warned, if you want your Glulx game to also be played by Linux and/or Mac players, you may be in for a big disappointment and/or a lot of debugging. And even then it may not work. OTOH, a game developed with the Linux or Mac terp will probably work fine under Windows. But check it out with the "other" terp too -- Linux or Mac. And note that these incompatibilities have also been experienced by everyone writing a Glulx game, not just me -- although "Carma" is probably the most graphic/sound intensive Glulx game written to date.

    I've always maintained that I am a game writer, not an interpreter writer, ergo it is not my job to fix or compensate for interpreters. And, frankly, I see no flaw in that argument. ;-) So while I really like Glulx's windowing system, I'm outta here!

    Doe 7/29/03

     Part One      Part Two      Part Three      Top of Page
     Appendix One (infglk Wrapper Reference)
     Appendix Two (Interpreter & Color Charts)

Monkey in dunce cap.