I’m having some very odd problems trying to display graphics. Consider the following story (which I’ve greatly simplified; e.g. I hard-coded the scaled dimensions instead of computing them from the results of glk_image_get_info):
Foo is a room.
Release along with an interpreter.
Figure of zonk is the file "foo.png".
When play begins, spifflicate the Glulx resource ID of the figure of zonk.
To spifflicate (N - a number): (- Draw({N}); -).
Include (-
[ Draw rid reta retb;
glk_image_get_info(rid, gg_arguments, gg_arguments+WORDSIZE);
new_line;
reta = glk_image_draw(gg_mainwin, rid, imagealign_InlineCenter, 0);
retb = glk_image_draw_scaled(gg_mainwin, rid, imagealign_InlineCenter, 0, 60, 60);
print "^", reta, ",", retb;
];
-).
Trying this code under 5 different interpreters gives 4 different results!
Quixe: both images, one next to the other; return values both 1
Gargoyle: both images, one above the other; return values both 1
Glulxe in the Inform application, Zoom: only the unscaled image; return values both 0
Spatterlight: neither image; return values both 1
It’s not clear to me if the Glk specification settles whether (1) or (2) is the correct behavior. But (3) and (4) seem seriously wrong. Bizarrely, commenting out either the call to ‘glk_image_get_info’ or the ‘new_line’ causes Spatterlight to switch to behavior (1). Is the code above illegal somehow, maybe triggering undefined behavior?
I’m finding similar inconsistencies when trying to compute the size for my scaled image. I want it to scale with the size of the window I’m drawing it in, so I’m calling glk_window_get_size to find the window’s width. The Glk spec basically says that for a text buffer window I should get back the number of characters that fit in one line, which is indeed what I get from Quixe, Gargoyle, and Spatterlight. But Zoom and the Glulxe in Inform return much larger numbers which are probably the width in pixels. Is this a mistake in the Glk library they use?
Obviously I need the window width in pixels, since the image sizes are given in pixels. So I figured I’d use glk_style_measure to determine the size of the font, so I can roughly convert characters-per-line to pixels-per-line. Zoom and Glulxe in Inform return the font size in points, but Gargoyle always returns the useless value 1 (which according to the Glk spec means it doesn’t support different font sizes). Spatterlight returns 0 (thank you very much!). So it seems that this approach just won’t work. Is there a better way to work out the width in pixels of a text buffer window?
The basic problem here is the lack of maintenance of OS X Glulx interpreters: Spatterlight hasn’t been updated in years, and Zoom and Gargoyle both don’t seem to have anyone interested in updating them any more.
Unfortunately (or “because Zarf isn’t so smart”) the Glk API doesn’t offer a good way to do what you want. (Measure the width in pixels of a text window, for image-scaling reasons.)
Trying to multiply glk_window_get_size() and glk_style_measure() values is two points of failure – not only the bug mentioned above, but glk_style_measure() is the next thing to deprecated. I didn’t implement it at all in Quixe; trying to interrogate text feature through all the layers of HTML and CSS feels like solving the wrong problem.
A better approach (but still hacky) is to open a graphics window first, measure it, and then close it.
Thanks to both of you. Creating a graphics window and measuring that seems to work perfectly.
On the issue of buggy OS X Glulx interpreters: is it just the case that people rarely use anything but the simplest graphics capabilities, so these issues don’t arise? Or are there more reliable interpreters for other platforms? In my experiments, Quixe had the most correct behavior in addition to being the most fully-featured (only missing sound, amongst the handful of features I care about), but I figured I should try to support as many interpreters as possible. Is that a lost cause?