Glulx and Glulx Inform

There are, as noted in previous sections, many virtual machines out there designed for IF. Some of them -- the TADS VM and the Hugo VM, for example -- can do things the Z-machine can't. They can handle games larger than 512 kilobytes, for instance, and getting them to show pictures or play sounds is much less awkward than getting the Z-machine to do the same. However, to use one of them, you have to learn the associated language: TADS or Hugo. Many Inform programmers put a significant investment of time and energy into learning Inform, and would prefer not to have to start learning how to program IF from scratch.

Glulx was designed to solve this problem. Glulx is a 32-bit virtual machine (footnote) whose compilers are designed to take Inform code and convert it into Glulx code. Thus, Inform programmers can leave behind the restrictions of the Z-machine and take advantage of Glulx's extra capabilities without having to learn a new language. For the most part.

You may recall from the Glk section that there was one notable exception to the rule that data processing and input/output are separate in IF programming. The exception occurs when programmers insert opcodes into their programs.

An opcode is an instruction that bypasses some of the usual steps in the programming process. Imagine this process as a tower of robots standing on each other's shoulders. Each robot only talks to the robot below it. So a robot near the top tell the next robot down, "Here, print this sentence." And that robot, the I/O robot, tells the next robot down, "Okay, print the letter A at this screen position in this color, and then print the letter B at this position in this color..." And that robot translates that into, "Put white dots here, here, here, here, here..." Eventually you see little white dots on your screen that appear to form letters which form words which you interpret as part of a story.

But what if you didn't want to leave it up to the robots to determine where the letters should go and what they should look like? What if you wanted to push one of the robots out of the way and tell the I/O robot directly, "Okay, I want the letter Q, in boldface, at screen position (1,5), and make it bright green"? This is where opcodes come in. Normally, if your game is in Inform, you write all your instructions in Inform, then have the compiler convert it into machine code. But sometimes, when you want more direct control -- such as when you're customizing your status line, or if you want to put special effects in the game like words that dance around on the title screen -- you need to put in opcodes. If you're compiling for the Z-machine, these opcodes are written in Z-assembly, and look like "@set_colour 2 4;" (which means "print in black text on a green background") or "@read_char 1 8 Dummy i;" (which means "either wait for a key to be pressed or for eight-tenths of a second, whichever comes first"). Z-assembly opcodes are covered in the Inform designer's manual, and for a long time was considered by most to be just another part of Inform.

However, the arrival of Glulx changed things. See, regular Inform compilers know how to change Inform source code into Z-machine code and how to change Z-assembly opcodes into Z-machine code. But while Glulx Inform compilers know how to change Inform source code into Glulx code, Z-assembly looks like gibberish to them. Glulx compilers need all opcodes to be written for Glk. This includes the ones in the Inform library, so the standard Inform library doesn't work with Glulx: you need to use the special bi-platform Inform library (which is designed to be able to be used with games targeted for either Glulx or the Z-machine).

This means that any knowledge Inform authors have picked up involving Z-machine opcodes is basically useless for creating Glulx games. If they want to compile for Glulx, they have to learn a whole new set of procedures for specifying text styles, creating special effects, displaying images, playing music and the like. And that's what section two is about.