As noted earlier, those wishing to compile their existing Inform source code to Glulx have to make sure that they replace any Z-assembly with Glulx assembly (or calls to Glulx Inform routines that do what the Z-assembly did.) The other major change game programmers might have to make is to replace any calls like "style bold;" and "style underline;" -- Glulx doesn't recognize them. Instead, you need to make Glulx Inform style calls.
Glulx Inform style calls work much the same way as regular Inform style calls. You use the glk_set_style() command with the style you want to apply in the parentheses, and any text printed after that will appear in the specified style. There is no "turning off" a style, as with HTML and its </style> tags -- to resume printing text normally, simply insert the line "glk_set_style(style_Normal);". Your other choices include:
So what exactly do each of these look like? It varies by interpreter. style_Emphasized might be boldface, or italic, or simply bright. You can, however, make suggestions concerning various aspects of a particular style (including two styles which are left for the game programmer to define: style_User1 and style_User2.) Some interpreters will heed these suggestions; others won't. (And some will heed them incorrectly: at the time Gull was first written DOS and Allegro Glulxe got foreground and background color suggestions backwards!) At present, there's no "gestalt_StyleHints" or anything like that to check whether or not your suggestions are being ignored. But if you're feeling lucky, use the glk_stylehint_set() call, which takes four arguments:
1) The type of window in which this style hint should apply. Your choices are wintype_TextBuffer, wintype_TextGrid, or wintype_AllTypes (but not wintype_Graphics, since you can't print text to a graphics window.)
2) The style to which this style hint should apply.
3) The aspect of the style to be affected (list to follow).
4) The number or constant which indicates how that aspect of the style should be affected.
The meaning of the fourth argument varies drastically depending on what the third argument is: "1" could mean "indent a small amount", "bold", "almost black", or many other things depending on context. Thus, the third and fourth arguments shouldn't really be considered separately, but in tandem. Here's a table of currently supported combinations:
| ASPECT (3rd arg) | VALUE (4th arg) |
|---|---|
| stylehint_Indentation | This should be a number, meaning "move the following block of text this many units to the right" (so negative numbers will actually move the text to the left.) How big is a unit? It varies by interpreter. |
| stylehint_ParaIndentation | This is just like stylehint_Indentation, but it only affects the first line of each paragraph. |
| stylehint_Justification | You have four constants to choose from: stylehint_just_LeftFlush (left justification), stylehint_just_RightFlush (right justification), stylehint_just_LeftRight (full justification), and stylehint_just_Centered (centered). |
| stylehint_Size | This should be a number, but not an absolute number (like point size); instead, 0 means "use the default font size", while positive numbers increase the font size by a certain number of increments and negative numbers decrease it. Increments are not necessarily the same size: if 0 is 12-point, and +1 is 14 point, +2 might be 18-point. |
| stylehint_Weight | 0 = normal; 1 = bold; -1 = light. |
| stylehint_Oblique | 0 = not italic; 1 = italic. |
| stylehint_Proportional | 0 = fixed-width font; 1 = proportional font. |
| stylehint_TextColor | This should be a 32-bit number representing the color to be used. Far and away the easier way to render this is in hex (footnote), which is done as follows. First, type a dollar sign (which indicates that a hex number is to follow.) Next, type a two-hex-digit number, from 00 to FF, representing the amount of red to appear in the color. Then comes a two-hex-digit number to represent the amount of green, and then a two-hex-digit number to represent the amount of blue. Thus, $000000 would be black, $FFFFFF would be white, $FF0000 would be bright red, $FFC000 would be a nice goldenrod, $C0C0FF would be baby blue, and so on. |
| stylehint_BackColor | This is a 32-bit number exactly as above, only this time you're selecting the color that is to appear behind the text. However, if this isn't the background color of the window itself, the results are bound to be exceedingly ugly on some interpreters. (Here's a screen shot.) At present there is no style hint for suggesting the background color of the window itself; however, there is a sort of unofficial standard that the background color of a window should be the same as the BackColor of style_Normal at the time of the window's creation. |
| stylehint_ReverseColor | 0 = print normally; 1 = print with background color on top of foreground color. |
So, putting it all together, let's say you wanted to define style_User1 as red text on a black background. This would be accomplished with the following code:
glk_stylehint_set(wintype_TextBuffer, style_User1,
stylehint_TextColor, $FF0000);
glk_stylehint_set(wintype_TextBuffer, style_User1,
stylehint_BackColor, $000000);
However, style hints only affect subsequently created windows. This means that if you want to use them, you need to set them before you create the window where you want them to appear. And since gg_mainwin is created by the library, if you want them to appear in the regular story window, putting your style hints in Initialise() is too late -- you need to use the InitGlkWindow() entry point. InitGlkWindow() is called several times, passing a different value each time; in this case, you want to declare your style hints if the value is equal to the rock value of gg_mainwin, like so:
[ InitGlkWindow winrock;
switch (winrock) {
GG_MAINWIN_ROCK:
glk_stylehint_set(wintype_TextBuffer, style_User1,
stylehint_TextColor, $FF0000);
glk_stylehint_set(wintype_TextBuffer, style_User1,
stylehint_BackColor, $000000);
}
rfalse; ! leaving out this line will lead to a messy crash!
];
One last note before moving on. It may seem to you that code like
print "I said, violence is "; glk_set_style(style_Emphasized); print "not"; glk_set_style(style_Normal); print " the answer to this one.";
is more than a little unwieldy. It is. On the other hand, it's not much worse than
print "I said, violence is "; style bold; print "not"; style roman; print " the answer to this one.";
This is why many IF authors already use small routines to make this sort of thing much smoother. There's no need to type "style_Emphasized" a hundred times; something like this will do nicely:
[ b text;
glk_set_style(style_Emphasized);
print (string) text;
glk_set_style(style_Normal);
];
And once you've created that routine, you can then render the example sentence like so:
print "I said, violence is ", (b) "not", " the answer to this one.";