I mean, IF is Not the first field to have a need for cross-platform text-based
I/O. There are already very nice systems out there to accomplish this.
In fact, from what I've seen, it seems the Unix port of GLK is actually /Based/
on Curses, a very old, very stable, very flexible I/O library that works on
just about every single platform I can think of.
It this a reinvintion of the wheel? And if so, um, why?
(No offense to anyone in the project -- I probably just missed something, and
you know just what your doing, but I'd like to be let in on it... :)
Lat I checked, curses limits you to text only. GLK allows for considerably
more elaborate I/O.
But I think I'd better let Zarf field this one.
"My eyes say their prayers to her / Sailors ring her bell / Like a moth
mistakes a light bulb / For the moon and goes to hell." -- Tom Waits
Okay. There are two purposes, one obvious and one obvious.
The obvious goal is to provide an I/O API (not library) which is
*abstract* enough to *not* specify a UI.
You gave the example of Curses. That's a low-level, concrete API. It can
certainly be implemented on the Mac, for example. But a program that uses
Curses directly cannot possibly provide a Mac user interface, with Mac
scrollbars, proportional fonts, a resizeable window, Mac-style editing of
the input line, and so on. It will always look like a program running in a
fixed-width terminal window.
This is Unacceptable to me, after years of maintaining MaxZip and MaxTADS.
Really, the logic went the other way around. I looked at MaxZip and
MaxTADS and thought, jeez, I've got nearly identical Mac UI code layered
on top of nearly platform-independent game engine. Why not formalize that
separation, and have *the same* Mac UI library layered on top of
*completely* platform-independent game engines?
To this point, I have succeeded. My first test program was Dungeon. I now
have a C program which can be compiled without *any* changes on Mac, Unix,
Windows, etc. Linked with the appropriate library, it acquires a
completely Macintosh-native UI, or Windows, or X, or Curses. It works.
Now the second goal, which is trickier, is to have a uniform dispatching
mechanism. This is meaningful only for game systems that use virtual
machines, not for C programs.
Consider Glulx, the VM I'm designing to complement Glk. The VM has no
built-in knowledge of windows, files, graphics, and so on. (Unlike the
Z-machine, which has opcodes specifically for manipulating windows,
drawing graphics, etc.) Instead, all I/O goes through a single @glk
This means that I can add a new capability to Glk (for example, networking
for multiplayer games.) This does *not* require a change in the
interpreter. Someone has to implement that networking code for (say) the
Mac, in the Mac Glk library; and then rebuild the interpreter with the new
library. But it avoids the Z-machine trap of having to extend the engine
for every I/O change. There's a precise demarcation between the game, the
interpreter, and the I/O module.
(With shared libraries, in fact, you might be able to rig your system so
that the interpreter program doesn't change at all. Drop in the new shared
Glk library, and games can immediately make use of it.)
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
Actually, now that I've written the long reply, I should also add that Glk
allows for *simpler* I/O as well.
This is not a mere curiosity. There's a Glk library for Unix that dumps
all its output into stdout, as a raw stream. Folks have connected that to
a networked MUD client -- producing a MUD robot that plays IF games on the
MUD. That's easy with a simple stream interface. It would be much trickier
if the interface was necessarily Curses.
That's the first time I've understood what GLK is.
You need to put that exact wording on your homepage.
> M. David Krauss <Fa...@frodo.com> wrote:
>> Hello all. It's been a long time since I was last able to hang around here,
>> I think I've missed a few things. All apologies if I'm rehashing something
>> here, but I just found out about GLK, and um.. I don't get it.
>> I mean, IF is Not the first field to have a need for cross-platform
>> I/O. There are already very nice systems out there to accomplish this.
>> In fact, from what I've seen, it seems the Unix port of GLK is actually
>> on Curses, a very old, very stable, very flexible I/O library that works on
>> just about every single platform I can think of.
GLK is a much higher level abstraction.