Glk and Glulx

1 view
Skip to first unread message

dgr...@cs.csuabk.edu

unread,
Oct 6, 2001, 2:53:54 PM10/6/01
to

How much does Glulx depend on Glk, if at all? I'm thinking of adding the
Glulx VM to Unix Frotz sometime soon.


--
David Griffith
dgr...@cs.csubak.edu

Matthew T. Russotto

unread,
Oct 6, 2001, 4:42:07 PM10/6/01
to
In article <9pnk02$1bnqu$1...@hades.csu.net>, <dgr...@cs.csuabk.edu> wrote:
}
}How much does Glulx depend on Glk, if at all? I'm thinking of adding the
}Glulx VM to Unix Frotz sometime soon.

If you want I/O, you need Glk. Otherwise, you can get away without
it.

--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."

Jon Zeppieri

unread,
Oct 6, 2001, 7:16:02 PM10/6/01
to
dgr...@cs.csuabk.edu wrote in message news:<9pnk02$1bnqu$1...@hades.csu.net>...

> How much does Glulx depend on Glk, if at all? I'm thinking of adding the
> Glulx VM to Unix Frotz sometime soon.

Based on the specification (particularly section 1.1), it seems fairly
clear that Glulx does not depend on Glk. The parenthesis:

(If the interpreter supports Glk, for example, the glk opcode
will always function.)

...is good evidence for this.

Presumably, all you need is enough I/O power to handle the Glulx's I/O
opcodes (e.g. streamnum, streamchar, &c.).

*However*, Glulx programs have to tell the VM (by means of the
setopsys opcode) which I/O system they will use. I imagine that every
Glulx game that currently exists depends upon the glk opcode, which is
provided by the Glk I/O system. (There is, for instance, no way using
pure Glulx operations alone to open a window.)

So, here's the problem: if you want your Glulxified Frotz to work
with any game that depends upon the Glk I/O system, then you need, in
one way or another, to implement Glk (even if it's only in terms of
what is already provided by Frotz). If you want it to work only for a
substantial subset of such programs, you can lie to the programs and
tell them that your 'terp does, in fact, support Glk (whereas in
reality in merely supports the more commonly used features of Glk).
Or, you could provide a new, distinct I/O subsystem. But then
programs would have to be written specifically for that subsystem.

Matthew T. Russotto

unread,
Oct 6, 2001, 9:00:31 PM10/6/01
to
In article <e61ef191.01100...@posting.google.com>,

Jon Zeppieri <97...@my-deja.com> wrote:
}
}what is already provided by Frotz). If you want it to work only for a
}substantial subset of such programs, you can lie to the programs and
}tell them that your 'terp does, in fact, support Glk (whereas in
}reality in merely supports the more commonly used features of Glk).

You actually need to support little of Glk to be compliant -- look at
CheapGlk.

Jon Zeppieri

unread,
Oct 7, 2001, 11:12:43 AM10/7/01
to
russ...@wanda.vf.pond.com (Matthew T. Russotto) wrote in message news:<PONv7.76$9d.2...@newshog.newsread.com>...

> In article <e61ef191.01100...@posting.google.com>,
> Jon Zeppieri <97...@my-deja.com> wrote:
> }
> }what is already provided by Frotz). If you want it to work only for a
> }substantial subset of such programs, you can lie to the programs and
> }tell them that your 'terp does, in fact, support Glk (whereas in
> }reality in merely supports the more commonly used features of Glk).
>
> You actually need to support little of Glk to be compliant -- look at
> CheapGlk.

True, but let me clarify what I meant.
If your Glulx VM reports that it supports the Glk I/O system (and the
specification strongly suggests that it doesn't have to support it at
all), then the glk opcode has to work. That doesn't mean every
feature of Glk has to be present, but, for instance, if you try to
split an existing window, and the Glk implementation doesn't allow any
more than a single window (as is the case with CheapGlk) then the call
should return zero. It shouldn't, for instance, result in a fatal VM
error. This is what I mean by "supporting" Glk. I just mean that the
API is understood, even if it's trivially implemented.

OKB -- not okblacke

unread,
Oct 7, 2001, 12:42:10 PM10/7/01
to
russ...@wanda.vf.pond.com (Matthew T. Russotto) wrote:
>}If you want it to work only for a
>}substantial subset of such programs, you can lie to the programs and
>}tell them that your 'terp does, in fact, support Glk (whereas in
>}reality in merely supports the more commonly used features of Glk).
>You actually need to support little of Glk to be compliant -- look at
>CheapGlk.

Just tossing in my personal opinion here: yes, you CAN do this, but I
don't think it's a good idea. I am apprehensive that if terp authors move in
this direction, we'll wind up with a bunch of Glulx/Glk implementations that
really don't supply any of the features that people want to get by using Glulx.
(I mean this without animosity to anyone who may have written or be writing
such a terp, but as an example: if your terp doesn't pay attention to
stylehints and only supports one window, what's the point?) This then puts the
burden on the game author to check all of this himself, and I think this should
be minimized.

Basically, I think there is an important distinction between "what you
officially need to comply with the spec" and "what everybody thinks Glulx
does". It seems that many people who are considering moving to Glulx are doing
so because they want better style control, better window control, and graphics
and/or sound capabilities. The fewer of these you support (or the less
thoroughly you support them), the less meaningful it is to say "This is a
Glulxe terp." (Another important draw of Glulx is that the game can be as big
as you want, but hopefully no one is considering writing a terp which won't
load games bigger than a certain size.)

As far as "lying" to the game and saying "Yeah, I really do support
such-and-such Glk stuff" when you really don't, that could be even worse,
because then even if the game author DOES do all that checking himself, it
still might not work right.

--OKB (Bren...@aol.com) -- no relation to okblacke

"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown

Matthew T. Russotto

unread,
Oct 7, 2001, 2:20:46 PM10/7/01
to
In article <20011007124210...@mb-cg.aol.com>,

OKB -- not okblacke <bren...@aol.comRemove> wrote:
}russ...@wanda.vf.pond.com (Matthew T. Russotto) wrote:
}
} (I mean this without animosity to anyone who may have written or be writing
}such a terp, but as an example: if your terp doesn't pay attention to
}stylehints and only supports one window, what's the point?)

In my case, and thus the case of the unfinished and mostly-abandoned
Java Glulx, the point is that I don't mind writing VM code but I
really hate writing UI code. So I wrote a dirt-simple System.out/System.in
based Java version of CheapGlk, just to support interpreter development.

}This then puts the
}burden on the game author to check all of this himself, and I think this should
}be minimized.

The spec is the spec. A game author fails to check for optional
features at his own peril. Or some beta-tester will run it under
CheapGlk and cackle as the author pulls his hair out.

} Basically, I think there is an important distinction between "what you
}officially need to comply with the spec" and "what everybody thinks Glulx
}does".

If there is such a distinction, "everybody" should be made to re-read
the spec and try CheapGLK.

L. Ross Raszewski

unread,
Oct 7, 2001, 6:07:45 PM10/7/01
to
On Sun, 07 Oct 2001 18:20:46 GMT, Matthew T. Russotto
<russ...@wanda.vf.pond.com> wrote:
>If there is such a distinction, "everybody" should be made to re-read
>the spec and try CheapGLK.

It's not so much an issue of people "thinking" glk does more than it
does; it's a matter of the spec beign *so* allowing of "limited"
implementations that no one really cares that Glk is technicaly
allowed to offer a subset of its abilities. Frankly, no one who's terribly
interested in a multimedia game is going to be willign to make his
game run in an environment that doesn't even support a status line. A
Glk implementation that only supports the barest minimum of what the
spec requires isn't going to be useful as anything more than a toy.

Adam Thornton

unread,
Oct 7, 2001, 8:43:48 PM10/7/01
to
In article <ts1khh5...@corp.supernews.com>,

Not to mention that there's a lot of ambiguity in what "supporting" a
feature means.

Let's take--as a purely random example, not one that I ever would have
encountered or anything--AIFF sound.

WinGlk handles AIFF sounds fine, and will play things that are
mostly-AIFF-encoded but aren't actually quite legal AIFFs.

DOSGlk gets upset if an AIFF has anything except a single sound chunk.
This is problematic for me, in that I put together my sounds with the
program "snd" on Linux, and it saves with other chunks that contain
useless, but legal and harmless, header material. Which would be fine:
they're legal AIFFs, and nothing in the Glulx standard forbids them, but
DOSGlk won't play these sounds.

Linux doesn't support AIFFs out of the box with xglk. But there are at
least 3 options available. The first and best is to use Torbjorn
Andersson's patched SDL_mixer and his sdl_mixer sound support. This
seems to play pretty much everything WinGlk does, except that, due to
the way SDL_mixer works, your sound needs to be saved at some power of
two multiple of 11025 Hz; otherwise it is simply resized to fit, which
can sound very strange indeed. The second option is to use my sox-based
support. This also works, but at least one popular Windows file format
converter saves something that smells kind of like an AIFF--close enough
for WinGlk and SDL_mixer to play it--but not enough like an AIFF for sox
to play it. Third option: Adrian Chung's patches. These don't support
sound notification when the sound is done, which, depending on how
you've structured your game, may be significant. I don't actually know
how large a subset of AIFF-like-things it handles, because I needed
sound notification and thus didn't use those patches much.

Mac: plays AIFFs fine. Except that the Mac assumes that your samples
are in signed byte format. The Windows program that produces the files
that sox is unhappy with also produces files with 16-bit sound samples.
It's also certianly an option with SND. And nowhere is it documented
that, by the way, if you use a 16-bit sample with Mac Glulxe, your
sounds will sound horrible because, essentially, every other sample is
white noise.

This makes it horribly and unnecessarily frustrating to produce a truly
cross-platform game with Glulx. Even if you're being good. Only
through trial and error would you discover that to play your songs
equally well on all of the interpreters that claim to support AIFF
sounds, you need an AIFF that:
a) has only a single sound chunk
b) uses 8-bit signed samples
c) is sampled at ..., 5512.5, 11025, 22050, 44100, ... Hz.

After the Comp I'll have a proper rant about it, and I don't think I
will be the only one.

Adam


OKB -- not okblacke

unread,
Oct 7, 2001, 11:32:39 PM10/7/01
to
lrasz...@loyola.edu (L. Ross Raszewski) wrote:
>It's not so much an issue of people "thinking" glk does more than it
>does; it's a matter of the spec beign *so* allowing of "limited"
>implementations that no one really cares that Glk is technicaly
>allowed to offer a subset of its abilities. Frankly, no one who's terribly
>interested in a multimedia game is going to be willign to make his
>game run in an environment that doesn't even support a status line. A
>Glk implementation that only supports the barest minimum of what the
>spec requires isn't going to be useful as anything more than a toy.

Exactly. What I meant by saying people "think" it does more is that when
people think to themselves "hey, maybe I'll try Glulx", they're not thinking
"hey, maybe I'll port my game to another VM just for laughs", they're thinking
"hey, I want graphics and/or windows and/or sounds, therefore I'll use Glulx".


I'll also be frank and say that I really think the spec should reflect
this, and I absolutely and fervently hope that terp writers keep this at the
forefront of their priority list when writing a terp.

L. Ross Raszewski

unread,
Oct 8, 2001, 2:38:17 AM10/8/01
to
On Mon, 8 Oct 2001 00:43:48 +0000 (UTC), Adam Thornton <ad...@fsf.net> wrote:
>Let's take--as a purely random example, not one that I ever would have
>encountered or anything--AIFF sound.
>DOSGlk gets upset if an AIFF has anything except a single sound chunk.
>This is problematic for me, in that I put together my sounds with the
>program "snd" on Linux, and it saves with other chunks that contain
>useless, but legal and harmless, header material. Which would be fine:
>they're legal AIFFs, and nothing in the Glulx standard forbids them, but
>DOSGlk won't play these sounds.

Yeah, but that's because GlkDOS was written by a hapless fool who
didn't know the AIFF specification, and had to write his own AIFF
decoder because there wasn't any extant DOS code for it.

Andrew Plotkin

unread,
Oct 8, 2001, 11:18:41 AM10/8/01
to
Adam Thornton <ad...@fsf.net> wrote:

> This makes it horribly and unnecessarily frustrating to produce a truly
> cross-platform game with Glulx. Even if you're being good. Only
> through trial and error would you discover that to play your songs
> equally well on all of the interpreters that claim to support AIFF
> sounds, you need an AIFF that:
> a) has only a single sound chunk
> b) uses 8-bit signed samples
> c) is sampled at ..., 5512.5, 11025, 22050, 44100, ... Hz.
>
> After the Comp I'll have a proper rant about it, and I don't think I
> will be the only one.

After the Comp, we (authors of various Glk libraries) will have a
decent base of experience to actually make sound work right on
them. :(

The reason I picked AIFF was that I figured it was written a long
time ago, and by a single well-accepted specification, so that I could
rely on it instead of having to invent my own sound format. It appears
that I was wrong. Double :(

(When I say "invent my own sound format", I don't mean that I'm going
to throw away AIFF and start over. But if I have to specify particular
AIFF variations in the Glk spec, then all Glk library authors have to
check all those variations by hand, and we may *not* be able to rely
on OS-native sound handlers. *And* we ought to check for, and at least
print warnings about, illegal AIFF variations, because if we don't
then authors will release games that only run on Windows. In other
words, all the pain of inventing my own sound format.)

(Or, library supporters might just drop sound support. You think *I*
want to write my own MacOS sound handler, if QuickTime's AIFF support
turns out to be flawed? Bugger that.)

L. Ross Rascetera:


> A Glk implementation that only supports the barest minimum of what the
> spec requires isn't going to be useful as anything more than a toy.

A toy such as Floyd (the MUD bot), or a IF interpreter for the
visually impaired.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.

Adam Thornton

unread,
Oct 8, 2001, 11:26:26 AM10/8/01
to
In article <9psg4h$ajf$1...@news.panix.com>,

Andrew Plotkin <erky...@eblong.com> wrote:
>(Or, library supporters might just drop sound support. You think *I*
>want to write my own MacOS sound handler, if QuickTime's AIFF support
>turns out to be flawed? Bugger that.)

FWIW, you don't have AIFF handled by QT *now*. Sounds played fine (mod
the 8-bit-sample thing) before I downloaded QT; pictures didn't.

I had an idea; I don't know how feasible it is, and it fixes the
symptom, not the problem, but:

The Linux port already uses SDL_mixer for its sounds (at least in the
Torbjorn Andersson variant which I've been enthusiastically recommending
to everyone). SDL exists for Windows and MacOS as well (and BeOS and a
couple other platforms). As far as I know it doesn't exist for DOS but
maybe with the DJGPP libraries/compiler that wouldn't be too hard--I
don't know. So maybe one thing to investigate would be to use SDL for
audio and video rendering, since that would buy us cross-platform
consistency at what might be an affordable price.

Adam

Andrew Plotkin

unread,
Oct 8, 2001, 12:04:31 PM10/8/01
to
Adam Thornton <ad...@fsf.net> wrote:
> In article <9psg4h$ajf$1...@news.panix.com>,
> Andrew Plotkin <erky...@eblong.com> wrote:
>>(Or, library supporters might just drop sound support. You think *I*
>>want to write my own MacOS sound handler, if QuickTime's AIFF support
>>turns out to be flawed? Bugger that.)

> FWIW, you don't have AIFF handled by QT *now*. Sounds played fine (mod
> the 8-bit-sample thing) before I downloaded QT; pictures didn't.

Ha, oops. I was mixing up my use of QT for JPEG/PNG with my use of the
older Mac Sound Manager API for AIFF.

Same principle applies, though.

> I had an idea; I don't know how feasible it is, and it fixes the
> symptom, not the problem, but:
>
> The Linux port already uses SDL_mixer for its sounds (at least in the
> Torbjorn Andersson variant which I've been enthusiastically recommending
> to everyone). SDL exists for Windows and MacOS as well (and BeOS and a
> couple other platforms). As far as I know it doesn't exist for DOS but
> maybe with the DJGPP libraries/compiler that wouldn't be too hard--I
> don't know. So maybe one thing to investigate would be to use SDL for
> audio and video rendering, since that would buy us cross-platform
> consistency at what might be an affordable price.

Hm. How consistent is it?

Torbjörn Andersson

unread,
Oct 8, 2001, 12:15:48 PM10/8/01
to
ad...@fsf.net (Adam Thornton) wrote:

> So maybe one thing to investigate would be to use SDL for
> audio and video rendering, since that would buy us cross-platform
> consistency at what might be an affordable price.

I see one possible problem with that: SDL doesn't provide any
functions for drawing text, and I don't know if the add-on libraries
for that are sophisticated enough.

So even with SDL as a portability layer for sound (and possibly
pictures), we'd probably have to look elsewhere for the actual GUI
parts. Any ideas? (I know Hugo uses wxWindows to good effect, but
that's C++, which I hardly know anything about.)

Torbjörn

dgr...@cs.csuabk.edu

unread,
Oct 8, 2001, 12:10:17 PM10/8/01
to
Andrew Plotkin <erky...@eblong.com> wrote:

> (When I say "invent my own sound format", I don't mean that I'm going
> to throw away AIFF and start over. But if I have to specify particular
> AIFF variations in the Glk spec, then all Glk library authors have to
> check all those variations by hand, and we may *not* be able to rely
> on OS-native sound handlers. *And* we ought to check for, and at least
> print warnings about, illegal AIFF variations, because if we don't
> then authors will release games that only run on Windows. In other
> words, all the pain of inventing my own sound format.)

> (Or, library supporters might just drop sound support. You think *I*
> want to write my own MacOS sound handler, if QuickTime's AIFF support
> turns out to be flawed? Bugger that.)

Perhaps the spec not allow any wiggle-room regarding AIFF variations. A
Glk implementation must support all AIFF listed in the spec or no sound at
all in order to be compliant.


--
David Griffith
dgr...@cs.csubak.edu

Andrew Plotkin

unread,
Oct 8, 2001, 12:30:24 PM10/8/01
to

That's what I just said.

It is probably the strategy I will be forced to undertake, but it has
the drawbacks I describe above.

Magnus Olsson

unread,
Oct 8, 2001, 12:49:27 PM10/8/01
to
In article <9psg4h$ajf$1...@news.panix.com>,
Andrew Plotkin <erky...@eblong.com> wrote:
>L. Ross Rascetera:
>> A Glk implementation that only supports the barest minimum of what the
>> spec requires isn't going to be useful as anything more than a toy.
>
>A toy such as Floyd (the MUD bot), or a IF interpreter for the
>visually impaired.

Or to play games where the windowing support or sound or pictures
are optional. Many HTML TADS games are still worth playing on a
non-HTML interpreter, and "Arthur" is still a great game without
the pictures.

--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------

Adam Thornton

unread,
Oct 8, 2001, 12:57:49 PM10/8/01
to
In article <9psj59$1c4ub$1...@hades.csu.net>, <dgr...@cs.csuabk.edu> wrote:
>Perhaps the spec not allow any wiggle-room regarding AIFF variations. A
>Glk implementation must support all AIFF listed in the spec or no sound at
>all in order to be compliant.

We need to nail down the same thing for MODs, too. Although for all I
know it's better nailed-down and it's my ignorance of the format that's
confusing me. I do know there are some mods in the Zeta Space demo that
soundtracker refuses to load, although libmikmod plays them fine in the
context of Linux Glk.

I think JPEG and PNG are sufficiently well-defined that it isn't a
problem for them. And has anyone ever actually used the SONG format?

Adam


Torbjörn Andersson

unread,
Oct 8, 2001, 1:10:01 PM10/8/01
to
Andrew Plotkin <erky...@eblong.com> wrote:

> Hm. How consistent is it?

If you mean how similarly it behaves over different platforms, the
most recent CVS snapshots of SDL_mixer has its own AIFF loader and
includes a subset of MikMod for handling MOD files. So at least in
theory it should behave pretty much identically on all supported
platforms.

The latest *stable* version of SDL_mixer has a completely broken AIFF
loader and an older subset of MikMod which completely fails to
recognize some of the MODs used by the Zeta Space demo. :-)

Known limitations:

1) To mix sounds together SDL has to convert them all to a common
format. This includes converting them all to the same frequency,
and SDL's frequency converter can only do that by multiplying or
dividing the frequency by 2.

This sucks.

2) SDL_mixer requires each sound to be a separate file. So in the Glk
patch it will copy the sound from the Blorb file to a temporary
file, play it and remove it afterwards.

This also sucks.

3) The AIFF loader only implements the subset of AIFF/AIFF-C that I
understand. This means it looks for one COMM and one SSND chunk (in
no specific order), and that's it. It does not handle compressed
sound, etc.

It could be argued that this sucks.

4) SDL_mixer makes a distinction between music and sound. It can mix
any number of sound tracks, but only one music track at a time.
AIFF can be handled as either sound or music, but MOD can only be
handled as music.

While not a crippling limitation, it does suck a bit.

The good news is that Ryan Gordon is working on a new library,
SDL_sound, which should act as a backend for some future version of
SDL_mixer.

Unlike SDL_mixer, SDL_sound expects to link with the MikMod library
instead of including its own stripped down copy of the MikMod source.
I'm not sure what that will mean for portability. But since the only
output driver that needs to be working is the one that writes the
decoded sound to memory, it shouldn't be that big a problem.

SDL_sound should go some way towards fixing the limitations listed
above:

1) "We REALLY need to fix the damned audio converter."
-- Ryan C. Gordon, on the SDL_sound mailing list.

I don't know if that means fixing SDL's sound converter, or adding
a custom converter to SDL_sound, but at least it's a known problem.

2) SDL_sound reads the sounds from "SDL_RWops" pointers, which could
be a FILE pointer, a memory area, or something else. This should
kill the ugly tempfile handling.

3) The AIFF loader is just a rewritten version of the one in SDL_mixer
(I still don't understand the rest of the specification :-), but
improving it is on the TODO list. Any volunteers?

4) SDL_sound treats all sounds equally. Once SDL_mixer gets rewritten
to use it, only artistic judgement would stand in the way of
mixing, say, two MODs an MP3 and a couple of AIFFs together.

I don't know how far away this rosy future is. A few decoders are
still missing from SDL_sound, and it needs portability testing. Anyone
interested can follow its progress at <http://icculus.org/SDL_sound>.

As far as I know the SDL_mixer rewrite won't even start until
SDL_sound stabilizes.

Torbjörn

M Joonas Pihlaja

unread,
Oct 8, 2001, 1:13:48 PM10/8/01
to
On Mon, 8 Oct 2001, Adam Thornton wrote:

> In article <9psj59$1c4ub$1...@hades.csu.net>, <dgr...@cs.csuabk.edu> wrote:

[snip Wiggle room w.r.t MOD]

MOD format is nailed down. It's the reluctance of authors to be
constrained by it that could cause trouble down the line. (Maybe
it already has.)

> I think JPEG and PNG are sufficiently well-defined that it
> isn't a problem for them. And has anyone ever actually used
> the SONG format?

I like the availability of SONG format -- it allows the use of
samples that aren't hardwired into the MOD. Not sure how well
supported it is though.

Joonas

Matthew T. Russotto

unread,
Oct 8, 2001, 1:41:51 PM10/8/01
to
In article <9psiqf$ajf$2...@news.panix.com>,

Andrew Plotkin <erky...@eblong.com> wrote:
}Adam Thornton <ad...@fsf.net> wrote:
}> In article <9psg4h$ajf$1...@news.panix.com>,
}> Andrew Plotkin <erky...@eblong.com> wrote:
}>>(Or, library supporters might just drop sound support. You think *I*
}>>want to write my own MacOS sound handler, if QuickTime's AIFF support
}>>turns out to be flawed? Bugger that.)
}
}> FWIW, you don't have AIFF handled by QT *now*. Sounds played fine (mod
}> the 8-bit-sample thing) before I downloaded QT; pictures didn't.
}
}Ha, oops. I was mixing up my use of QT for JPEG/PNG with my use of the
}older Mac Sound Manager API for AIFF.
}
}Same principle applies, though.

Which doesn't explain why only 8-bit samples work; the Sound Manager
has supported 16 bit samples for a LONG time.

Adam Thornton

unread,
Oct 8, 2001, 1:56:35 PM10/8/01
to
In article <wkg08u6...@Tempo.Update.UU.SE>,

Torbjörn Andersson <d91...@Update.UU.SE> wrote:
>4) SDL_sound treats all sounds equally. Once SDL_mixer gets rewritten
> to use it, only artistic judgement would stand in the way of
> mixing, say, two MODs an MP3 and a couple of AIFFs together.

I just thought of a neat way to build a sound queue in glk, that would
let you specify a set of sounds you chained together, using
notification, so one fired when the first was done.

Yes, there are ways to do this from handle_glk_event already, but at
least the way I've tried relies on an ugly global variable. The Right
Way is going to use objects to represent sounds (or, perhaps, sets of
concurrent sounds, as in 4 above). I think Inform's containment model
provides enough of a singly-linked-list structure that it should be
straightforward to do.

Adam

Adam Thornton

unread,
Oct 8, 2001, 1:59:46 PM10/8/01
to
In article <zzlw7.105$bd.2...@newshog.newsread.com>,

Matthew T. Russotto <russ...@wanda.vf.pond.com> wrote:
>Which doesn't explain why only 8-bit samples work; the Sound Manager
>has supported 16 bit samples for a LONG time.

Endianness issue?

Data point: my "Mac" is Basilisk II (legal, even: picked up a
nonfunctional Quadra mobo with ROM for free), running with 32M of
(emulated) RAM, running OS 7.5.3.

Adam

Andrew Plotkin

unread,
Oct 8, 2001, 2:09:24 PM10/8/01
to
Matthew T. Russotto <russ...@wanda.vf.pond.com> wrote:
> In article <9psiqf$ajf$2...@news.panix.com>,
> Andrew Plotkin <erky...@eblong.com> wrote:
> }
> }Ha, oops. I was mixing up my use of QT for JPEG/PNG with my use of the
> }older Mac Sound Manager API for AIFF.
> }
> }Same principle applies, though.

> Which doesn't explain why only 8-bit samples work; the Sound Manager
> has supported 16 bit samples for a LONG time.

I'm wondering whether it was a problem with the endianness or the
signedness of Adam's 16-bit AIFF tests, rather than the 16-bitness per
se.

It's also quite possible that when I scrape the dead leaves off my
MacGlk sound code, I'll say "oops" and fix some stupid bug in the way
I used the SM API.

Marnie Parker

unread,
Oct 8, 2001, 2:13:40 PM10/8/01
to
>Subject: Re: Glk and Glulx
>From: Andrew Plotkin erky...@eblong.com
>Date: 10/8/2001 9:30 AM Pacific Daylight Time
>Message-id:

>That's what I just said.
>
>It is probably the strategy I will be forced to undertake, but it has
>the drawbacks I describe above.
>
>--Z

I was going to withhold comments until the comp was over, but this seems like
such a good time to pipe in, I will.

Because Glulx is such a new system, there are bound to be glitches. No one's
fault -- no shame, no blame. Using something is different than
creating/thinking about it in theory, so using something new and/or
previously-not-used-very-much-before is bound to bring up problems.

Problem one: sound compatibility.

As a game writer, not a terp programmer, I am going to assume I can put aifs
and jpgs created under Dos/Windows into a Glulx game and that it will play on
all terps. Most game authors will assume that. And 60-80% of Glulx game writers
will probably develop their Glulx games under Dos/Windows.

As a game writer, I don't feel qualified to go and write some terp patch that
will enable it to correctly play my sounds and display my graphics.I am not a
good enough programmer for that and/or I know very little about that.

And a great many game authors will have the same approach -- they will want to
write a game and not worry about the terps. They will assume the terps work in
a compatible manner.

So it came as a big shock to me when I found Carma's sounds were not playing
correctly under Linux. Luckily Adam and Torjborn fixed that.

And I didn't find out until a day or two before the comp deadline, mainly
because it was so hard to scarf up a Mac betatester, that they sounds didn't
play corrrectly with the Mac terp. No way I could have corrected that, because:
1.) I know diddly about sound files 2.) I know diddly about programming a
terp 3.) I don't have a Mac 4.) I didn't have time. The last was my problem, I
was sick eariler this summer and was working up to the last minute. But the
rest will be a major problem for all game writers who wish to use Glulx, that
are also not terp programmers.

Bottom line, Glulx terps should work with sounds and graphics in enough of a
compatible manner that a game writer really doesn't have to worry about it. So
that sounds/graphics created under one system will work under another system.

Problem two: programming differences

I also discovered programming differences between the Windows terp and the
Linux terp. Not major ones, but ones that made enough of a difference. Luckily
I did have Linux on my second drive and could track down a bug that appeared
with the Linux terp that did not occurr in the Windows terp. Due to Linux setup
problems on my system, however, the Linux terp I used was the one without
sound.

This last one, I am unsure what can be done about that. But it almost makes it
so that a Glulx game writer has to test their game on all terps.

Problem three: the blorb format

The blorb archive format leaves a lot to be desired. I am not sure it
compresses sound files at all. Sound files take up the most bytes, even if one
trims a music sound to under a minute.

Most people will download a large amount of bytes if they can break up the
download into several downloads. I.E. They might download a 10MB game if they
can do it in two downloads of an hour rather than one download of 2 hours. Or
three downloads of ... well, you get the idea.

If Glulx really is multimedia, and not just a all-text game multimedia add-on,
then this becomes a major problem. What I am trying to say is that we need to
change our thinking to multimedia thinking.

Currently if one uses a blorb, one cannot have separate sound files. Or any
kind of separate resource files. Right now it's either one or the other.
Everything in one blorb, or everything separate.

It would be nice to be able to combine the two. So one could put all one's
graphics into a blorb and have the sound files be a separate download.

OR be able to have more than one blorb. Maybe one for graphics and one for
sound.

Sound files really do take a lot of bytes. A lot more than graphics. Even if
compressed, they take more bytes apparently than any other type of file.

Well, those are my three cents.

Doe :-)


doea...@aol.com
Glulx/Glk for Dunces http://members.aol.com/doepage/glkdunces.htm
IF Art Gallery http://members.aol.com/iffyart/
IF Review Conspiracy http://www.textfire.com/conspiracy/
The Tame Computer http://members.aol.com/tamecomputer/

dgr...@cs.csuabk.edu

unread,
Oct 8, 2001, 2:33:00 PM10/8/01
to

At least for Unix Frotz, GTK will be used for building a GUI.

--
David Griffith
dgr...@cs.csubak.edu

Matthew T. Russotto

unread,
Oct 8, 2001, 2:37:53 PM10/8/01
to
In article <9pspii$86j$2...@news.fsf.net>, Adam Thornton <ad...@fsf.net> wrote:
}In article <zzlw7.105$bd.2...@newshog.newsread.com>,
}Matthew T. Russotto <russ...@wanda.vf.pond.com> wrote:
}>Which doesn't explain why only 8-bit samples work; the Sound Manager
}>has supported 16 bit samples for a LONG time.
}
}Endianness issue?

The Sound Manager supports both endians. At least it does NOW...

}Data point: my "Mac" is Basilisk II (legal, even: picked up a
}nonfunctional Quadra mobo with ROM for free), running with 32M of
}(emulated) RAM, running OS 7.5.3.

Buggy Sound Manager, probably. The Sound Manager was a bugfest from the getgo,
and IIRC had two rewrites before a decent version came out. I believe
Sound Manger 3.0 wasn't standard until 7.6. (though it could be
installed separately)

It could be Basilisk, also... I'd love to know how it manages to
emulate the Apple Sound Chip, considering the thing is undocumented
and strange. Maybe the author is a better reverse-engineer than I.

L. Ross Raszewski

unread,
Oct 8, 2001, 3:21:10 PM10/8/01
to
Out of curiosity, were these mods legal blorb mods? IIRC, zetaspace
uses mods in formats other than those approved for use in Blorb
(perhaps as a form of protest against the restrictiveness of the blorb
specification)

Adam Thornton

unread,
Oct 8, 2001, 3:32:32 PM10/8/01
to
In article <5omw7.138$bd.2...@newshog.newsread.com>,

Matthew T. Russotto <russ...@wanda.vf.pond.com> wrote:
>It could be Basilisk, also... I'd love to know how it manages to
>emulate the Apple Sound Chip, considering the thing is undocumented
>and strange. Maybe the author is a better reverse-engineer than I.

It also happened on Big Al's Mac. I don't know its vintage or OS level,
however.

Adam

Adam Thornton

unread,
Oct 8, 2001, 3:38:19 PM10/8/01
to
In article <ts3v56m...@corp.supernews.com>,

L. Ross Raszewski <lrasz...@loyola.edu> wrote:
>Out of curiosity, were these mods legal blorb mods? IIRC, zetaspace
>uses mods in formats other than those approved for use in Blorb
>(perhaps as a form of protest against the restrictiveness of the blorb
>specification)

In the words of Terry Pratchett, "Sodomy non sapiens," or "buggered if I
know."

Adam

L. Ross Raszewski

unread,
Oct 8, 2001, 3:44:50 PM10/8/01
to
On 08 Oct 2001 18:13:40 GMT, Marnie Parker <doea...@aol.com> wrote:
>
>I was going to withhold comments until the comp was over, but this seems like
>such a good time to pipe in, I will.
>
>Because Glulx is such a new system, there are bound to be glitches. No one's
>fault -- no shame, no blame. Using something is different than
>creating/thinking about it in theory, so using something new and/or
>previously-not-used-very-much-before is bound to bring up problems.
>
>Problem one: sound compatibility.
>
>As a game writer, not a terp programmer, I am going to assume I can put aifs
>and jpgs created under Dos/Windows into a Glulx game and that it will play on
>all terps. Most game authors will assume that. And 60-80% of Glulx
game writers
>will probably develop their Glulx games under Dos/Windows.
>

Well, I think that most authors should know by now that sound and
graphics are not available on all terps. Of course, broken sound and
graphics on some terps (looks sheepish) is something different
altogether.


>As a game writer, I don't feel qualified to go and write some terp patch that
>will enable it to correctly play my sounds and display my graphics.I am not a
>good enough programmer for that and/or I know very little about that.

As another data point, I problably *am* a good enough programmer for
that, and I'm sure as hell not going to do it either.

>
>And a great many game authors will have the same approach -- they will want to
>write a game and not worry about the terps. They will assume the terps work in
>a compatible manner.
>

This is the assumption that authors should make -- it's what Glk was
designed for.

Now, what a lot of people have been assuming, which isn't true, is
"SOund and graphics are always available". This isn't a safe
assumption, and it's an unsafe assumption **REGARDLESS** of
platform. There are any number of reasons that sound might not work in
a game -- the player is using an OS whose Glk doesn't support sound is
the case you consider, but there's also "the user has his sound card
turned off", "the user is deaf" and "THe user just doesn't want to be
pestered with your sound." Likewise graphics.

A plea to authors: YOu should have known this already. If it is *at
all* piossible to make your multimedia game function without the
multimedia, go the extra mile and do it.

I know that it was a major consideration for me in coding up GWindows
that you be able to easily switch the screen to a less-multimedia
format. Of course, it's up to the individual game to implement
this. (ANd I am not altogether free of guilt -- GWindows only checks
for the availability of about half the things it should)


>So it came as a big shock to me when I found Carma's sounds were not playing
>correctly under Linux. Luckily Adam and Torjborn fixed that.
>
>And I didn't find out until a day or two before the comp deadline, mainly
>because it was so hard to scarf up a Mac betatester, that they sounds didn't
>play corrrectly with the Mac terp. No way I could have corrected
that, because:
> 1.) I know diddly about sound files 2.) I know diddly about programming a
>terp 3.) I don't have a Mac 4.) I didn't have time. The last was my problem, I
>was sick eariler this summer and was working up to the last minute. But the
>rest will be a major problem for all game writers who wish to use Glulx, that
>are also not terp programmers.
>
>Bottom line, Glulx terps should work with sounds and graphics in enough of a
>compatible manner that a game writer really doesn't have to worry about it. So
>that sounds/graphics created under one system will work under another system.

It should be pointed out that these are not failings of Glk -- they're
failings of the Glk ports (which is, in turn, the fault of the fact
that until now, there weren't any nontrivial Glulx games to test them
on. A lot of GlkDOS's problems are the result of the fact that my
testing procedure was "compile multiwin. Run it. Compile graphics
test. Run it. COmpile Nitfol. Run it on sherlock. Compile Glulxe. Run
it on Sensory Jam")

>
>Problem two: programming differences
>
>I also discovered programming differences between the Windows terp and the
>Linux terp. Not major ones, but ones that made enough of a difference. Luckily
>I did have Linux on my second drive and could track down a bug that appeared
>with the Linux terp that did not occurr in the Windows terp. Due to Linux setup
>problems on my system, however, the Linux terp I used was the one without
>sound.
>
>This last one, I am unsure what can be done about that. But it almost makes it
>so that a Glulx game writer has to test their game on all terps.

This has always been true when you're doing something that goes beyond
the simple interface design. Even staying within the Z-machine, you
run into trouble -- quite a few Zcode games will break because of box
quotes or the status line if the screen isn't big enough. ANd witness
varicella.

>
>Problem three: the blorb format
>
>The blorb archive format leaves a lot to be desired. I am not sure it
>compresses sound files at all. Sound files take up the most bytes, even if one
>trims a music sound to under a minute.

Blorb does not compress at all. Zarf claims that "most multimedia
formats compress themselves", which is true -- most of the usual
compressors won't make a signifigant difference to jpegs or mp3s. One
notable exception, though, is AIFF. One could imagine a blorb file
consisting of, say, 32 sounds, none more than a few seconds in length,
taking over 1 megabyte of space.

>
>Most people will download a large amount of bytes if they can break up the
>download into several downloads. I.E. They might download a 10MB game if they
>can do it in two downloads of an hour rather than one download of 2 hours. Or
>three downloads of ... well, you get the idea.
>

Ooogah. The ability to support multiple blorb files is not
specifically impossible under glk's model. I think this would be an
excellent thing to do.

Now, one of my biggst gripes is that almost all existing Glulx
runtimes require that the game code be included in the blorb
file. This is *explicitly* not required by the specification, but to
my knowledge, only the DOS port has any mechanism for allowing a blorb
file to be loaded which does not have the ulx file in it. Since Glulx
game files themselves can be quite large, a game which makes only
minimal use of multimedia could easily find half its size taken up by
the game code. Separating them out would be a quick and easy way to
cut filesizes in half.


>If Glulx really is multimedia, and not just a all-text game multimedia add-on,
>then this becomes a major problem. What I am trying to say is that we need to
>change our thinking to multimedia thinking.
>

Yes. We don't have a lot of experience in this area.

>Currently if one uses a blorb, one cannot have separate sound files. Or any
>kind of separate resource files. Right now it's either one or the other.
>Everything in one blorb, or everything separate.

See, you run into a cross-platform nightmare then. OSes vary so much
that even *filenames* aren't portable. One of the motivations behind
the blorb specification is that it is desirable for all the resources
to be addressable in a platform independent way.

The ability to load unblorbed resources is, in fact, purely a
debugging nicety. You shoudl *never* release a game with non-blorb
resources, because it's then up to the individual user to put them in
a conditionthattheir terp can deal with them.

>
>It would be nice to be able to combine the two. So one could put all one's
>graphics into a blorb and have the sound files be a separate download.
>
>OR be able to have more than one blorb. Maybe one for graphics and one for
>sound.
>

Like I said above, "yes".

Andrew Plotkin

unread,
Oct 8, 2001, 4:15:09 PM10/8/01
to
L. Ross Raszewski <lrasz...@loyola.edu> wrote:
> On 08 Oct 2001 18:13:40 GMT, Marnie Parker <doea...@aol.com> wrote:
>>
>>Most people will download a large amount of bytes if they can break up the
>>download into several downloads. I.E. They might download a 10MB game if they
>>can do it in two downloads of an hour rather than one download of 2 hours. Or
>>three downloads of ... well, you get the idea.

> Ooogah. The ability to support multiple blorb files is not
> specifically impossible under glk's model. I think this would be an
> excellent thing to do.

I agree. It looks important enough to be worth putting in Glk as a
requirement (for the Blorb portion of each Glk library).

> Now, one of my biggst gripes is that almost all existing Glulx
> runtimes require that the game code be included in the blorb
> file.

I didn't have a good idea how much of a nuisance this would be, when I
was writing library code. But it does make sense to separate those --
both when considering the way IFComp games are uploaded, and when
considering the "multimedia optional" mindset that we're trying to
achieve here.

>>Currently if one uses a blorb, one cannot have separate sound files. Or any
>>kind of separate resource files. Right now it's either one or the other.
>>Everything in one blorb, or everything separate.

> See, you run into a cross-platform nightmare then. OSes vary so much
> that even *filenames* aren't portable. One of the motivations behind
> the blorb specification is that it is desirable for all the resources
> to be addressable in a platform independent way.

> The ability to load unblorbed resources is, in fact, purely a
> debugging nicety.

Agreed.

Adam Thornton

unread,
Oct 8, 2001, 4:29:17 PM10/8/01
to
In article <ts40hik...@corp.supernews.com>,

L. Ross Raszewski <lrasz...@loyola.edu> wrote:
>Now, one of my biggst gripes is that almost all existing Glulx
>runtimes require that the game code be included in the blorb
>file. This is *explicitly* not required by the specification, but to
>my knowledge, only the DOS port has any mechanism for allowing a blorb
>file to be loaded which does not have the ulx file in it. Since Glulx
>game files themselves can be quite large, a game which makes only
>minimal use of multimedia could easily find half its size taken up by
>the game code. Separating them out would be a quick and easy way to
>cut filesizes in half.

So, um, is DOS Glulxe the only terp that will correctly play your comp
entry?

>See, you run into a cross-platform nightmare then. OSes vary so much
>that even *filenames* aren't portable. One of the motivations behind
>the blorb specification is that it is desirable for all the resources
>to be addressable in a platform independent way.
>The ability to load unblorbed resources is, in fact, purely a
>debugging nicety. You shoudl *never* release a game with non-blorb
>resources, because it's then up to the individual user to put them in
>a conditionthattheir terp can deal with them.

If there's some way for a blorb to include blorb resources--effectively,
the equivalent of #include--and if programs are written to fail
gracefully if resources aren't available (I'm thinking here of something
like Doe's unglklib wrappers, which mostly just silently fail if you try
to draw to a window that doesn't support the operation, or try to use
graphics when the terp has told you it doesn't do graphics) (whoops, let
me rephrase that: what I mean by "silently fail" is simply that if I
call a drawing method in unglklib, and my terp doesn't support pictures,
then the drawing method just returns false. So I, as a game developer,
don't explicitly have to care--I call the method, if the terp does it,
great, if it can't, my program flow just continues)--then this would be
easy. Package all your sound files in the sound blorb; when your
program tries to play the sound, if it's not there, just quietly
return.

Adam

Adam Thornton

unread,
Oct 8, 2001, 4:32:41 PM10/8/01
to
In article <9pt2at$4i9$1...@news.fsf.net>, Adam Thornton <ad...@fsf.net> wrote:
>So, um, is DOS Glulxe the only terp that will correctly play your comp
>entry?

Der. Since it's a z6, not likely. DOSFrotz? What terps *do* support
blorb with zcode?

Adam

OKB -- not okblacke

unread,
Oct 8, 2001, 4:36:06 PM10/8/01
to
doea...@aol.com (Marnie Parker) wrote:
>Bottom line, Glulx terps should work with sounds and graphics in enough of a
>compatible manner that a game writer really doesn't have to worry about it.
>So
>that sounds/graphics created under one system will work under another system.

Yes. And windows, and stylehints, and whatever.

No, it doesn't mean that I want speakerless computer to play sounds, or
anything like that. But attempting to play sounds, or change the stylehint, or
whatever, should not do anything BAD.

I think the most potentially dangerous example of this is windows. If I
attempt to play a sound and it doesn't play, oh well. If I attempt to display
a graphic and it doesn't work, oh well. But if I attempt to rearrange the
window layout and it doesn't work, and then I go try to do something else,
assuming the window layout is as it is, the screen looks like garbage.

I think the solution to this is that terp needs to recognize when it
can't do something and let the player know, as opposed to just going along and
giving out nonsense. I would like to see terps with some kind of setting to
notify the user if, say, a window was supposed to be displayed and couldn't be,
just so the player knows where the problem lies. It's up to the player to play
on with the lousy-looking result if he wants, but at least he's not sitting
there scratching his head wondering what went wrong.

My basic point here is that Glk/Glulx is not portable if I have to put
code in my game to test what the terp supports TO PREVENT MALFUNCTIONS. It's
one thing to say, "I want this graphic to display because it's important to the
game, and so if it doesn't display I, as the author, am going to make the
aesthetic decision that I'm not going to let the game continue." It's another
thing to say, "I want this graphic to display, but the game can go on without
it. However, if I don't check for all the little error conditions,
everything's going to look all wacky on the screen." Decisions about what is
important the game as a game should be distinct from distinctions about what is
necessary to prevent technical problems.

The game author should not be expected to foresee all possible
combinations of supported and unsupported stuff (graphics/no sound/no windows
as opposed to no graphics/sound/windows, for example). The terp should know
its limits and make them clear to the player, and deal with things beyond its
capability in a graceful manner.

--OKB (Bren...@aol.com) -- no relation to okblacke

"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown

Adam Thornton

unread,
Oct 8, 2001, 4:42:35 PM10/8/01
to
In article <20011008163606...@mb-md.aol.com>,

OKB -- not okblacke <bren...@aol.comRemove> wrote:
> The game author should not be expected to foresee all possible
>combinations of supported and unsupported stuff (graphics/no sound/no windows
>as opposed to no graphics/sound/windows, for example). The terp should know
>its limits and make them clear to the player, and deal with things beyond its
>capability in a graceful manner.

This is also a job for library authors. Unglklib does it rather nicely,
as one example.

Another thing that helps immensely is simply *testing* your game under
other terps.

There is at least one glulx game in the competition this year that works
perfectly well under Linux Glulxe-built-with-glkterm and Linux
Glulxe-built-with-cheapglk. Now, granted, it's *even less* fun that way
than it is with graphics and sounds, but it's perfectly possible to play
the game to completion. *That*, it seems to me, is a job for the
author--if a game plays OK on one full-on-multimedia terp, one
terminal-only terp, and one stdio-only terp, then in an ideal world, it
would be fair to assume it would work anywhere. The hard part is
getting all the full-on terps to more or less agree on behavior.

Adam


Daniel Barkalow

unread,
Oct 8, 2001, 4:44:56 PM10/8/01
to
On Sun, 7 Oct 2001, L. Ross Raszewski wrote:

> On Sun, 07 Oct 2001 18:20:46 GMT, Matthew T. Russotto
> <russ...@wanda.vf.pond.com> wrote:
> >If there is such a distinction, "everybody" should be made to re-read
> >the spec and try CheapGLK.
>
> It's not so much an issue of people "thinking" glk does more than it
> does; it's a matter of the spec beign *so* allowing of "limited"
> implementations that no one really cares that Glk is technicaly
> allowed to offer a subset of its abilities. Frankly, no one who's terribly
> interested in a multimedia game is going to be willign to make his
> game run in an environment that doesn't even support a status line. A


> Glk implementation that only supports the barest minimum of what the
> spec requires isn't going to be useful as anything more than a toy.

On the other hand, it might make sense to have a glulx terp that matches
frotz as close as possible. That is, if you don't use @glk yourself, but
just go through the standard inform library, you get essentially the same
thing as if you had stuck to z5, except with much more memory
available. E.g., the status line is in inverse video rather than being
separated by a line of dashes, and things default to the frotz colors,
scrolling system, etc.

I, at least, think that frotz is better-looking than glkterm, for the
things it does. Considering the number of non-.blb glulx games in this
comp, it seems like memory size and window-handling are useful enough
without graphics and sound that this is worthwhile. It might be better,
though, to write a frotz-based glk implementation, rather than glulx
support for frotz.

-Iabervon
*This .sig unintentionally changed*

L. Ross Raszewski

unread,
Oct 8, 2001, 4:47:47 PM10/8/01
to

In theory, Nitfol. In practice, I'm not sure. The blorb
file is optional.

Sean T Barrett

unread,
Oct 8, 2001, 5:37:54 PM10/8/01
to
In article <9pslud$k9d$1...@news.fsf.net>, Adam Thornton <ad...@fsf.net> wrote:
>I think JPEG and PNG are sufficiently well-defined that it isn't a
>problem for them.

Actually it's a little bit subtler than that: JPEG and PNG are
both very well-defined, but they're also pretty complex, and full
of options. What they have going for them is a common portable
codebase: many JPEG implementations were based on the "Independent
JPEG Group" code--or whatever it was called--and the PNG
spec was released with corresponding source code to load them.
In fact, I bet if you implement a JPEG that's arithmetically encoded
instead of huffman code, lots of programs won't load it--it's patented
and wasn't included in the IJG code. I don't know how many programs
support JPEG's lossless encoding mode, either. (Moreover, I've
seen JPGs that IE wouldn't display but NS would, and vice versa.)

Both of these formats are really just compression formats, so it's
not that surprising that the code is trivially portable: the code
for them just produces a stream of uncompressed data (e.g. a raw
24-bit image), and it's still left to the platform author to display
it. Instead you see variations in the quality of the 24-bit support,
or handling of image scaling; but most platforms make just displaying
the image to the screen straightforward, since it's such a common
operation.

With audio you step more towards the realm of the game APIs, since
quality audio isn't as necessary in most apps, so platform support
for it is less streamlined.

The analogy to JPG and PNG for audio would be supporting mp3
and Ogg Vorbis *assuming you already have sound support working*.
Hey, decode into a buffer, and then play it. (Ok, plus streaming
that becomes a pain). A number of platforms seem to offer a
"here, I'll do all the work, you just tell me what to play and
I'll play it" facility (windows provides this for playing videos
and CDs and I assume for audio files), and those can be a real
convenience to use for developers who don't have significant demands
on it, but I don't think we can get away with it when we want our
audio files packed into blorb files and we want sound notifications
and suchlike.

I'm not drawing any conclusions here; I just want to point out where
the comparison to JPEG and PNG fails and hope maybe that gives people
some insight into how to deal with sound.

SeanB

L. Ross Raszewski

unread,
Oct 8, 2001, 5:39:29 PM10/8/01
to

Well, GlkDOS tries to do this. Indeed, winGLK can do this. For that
matter, glkTerm can be set up to do this. But I think
what's causing most people trouble isn't that the game doesn't come
out looking like frotz -- it's that they assume that when they try to
move beyond a frotz-like look and feel, the way it behaves in any glk
implementation is the way it behaves in *every* glk implementation.

David Kinder

unread,
Oct 8, 2001, 6:32:31 PM10/8/01
to
> on OS-native sound handlers. *And* we ought to check for, and at least
> print warnings about, illegal AIFF variations, because if we don't
> then authors will release games that only run on Windows. In other
> words, all the pain of inventing my own sound format.)

I'm not aware of any "bad" AIFF files that Windows Glk will play; given
that the current test version uses a hand-written decoder, I'd tend to
expect the reverse, i.e. that there will be legal AIFFs out there it won't
play. Having said that, I haven't read the AIFF spec in all its mind
numbing detail.

One thing I've discovered from recent Windows Glk work is that, relative
to graphics files, decoding sound files is hell on toast. No nice well
tested libraries to decode them, and as for the DirectSound documentation
on streaming buffers [author starts to shudder] ...

David

Adam Thornton

unread,
Oct 8, 2001, 6:45:11 PM10/8/01
to
In article <9pt9e1$s5i$1...@uranium.btinternet.com>,

David Kinder <D.Ki...@btinter-remove-to-reply-net.com> wrote:
>I'm not aware of any "bad" AIFF files that Windows Glk will play; given
>that the current test version uses a hand-written decoder, I'd tend to
>expect the reverse, i.e. that there will be legal AIFFs out there it won't
>play. Having said that, I haven't read the AIFF spec in all its mind
>numbing detail.

The AIFFs in Doe's "Just a Dream."

play--which uses sox under the hood--reports
sox: Bogus AIFF file: INSTrument but no MARKers.

However, xglk-with-SDL_mixer-patches and WinGlk (yes, the test version)
play them fine.

Adam

Jack Moffitt

unread,
Oct 8, 2001, 6:46:39 PM10/8/01
to

> What they have going for them is a common portable
> codebase:
...

> With audio you step more towards the realm of the game APIs, since
> quality audio isn't as necessary in most apps, so platform support
> for it is less streamlined.
>
> The analogy to JPG and PNG for audio would be supporting mp3
> and Ogg Vorbis *assuming you already have sound support working*.

MPEG does not really have a good reference implementation. The real
reference implementation is littered with bugs that even casual
listeners would find unacceptable.

Ogg on the other hand has a very robust reference implementation and
compiles out of the box (the mac code might need a few tweaks, but there
are project files for codewarrior, etc) on every system pretty much.
BSD, Linux, Win32, DOS, MacOS 9, OS X, OS/2, etc, etc.

You're only problem is getting audio out the speakers.

> Hey, decode into a buffer, and then play it. (Ok, plus streaming
> that becomes a pain).

The Ogg libs will take care of streaming for you to. All you need is
some way to play raw audio. The typical case is 44.1kHz, 2 channel.
It's trivial to do this portably in Unices, and easy even in Windows.
I've never done it on the Mac, but it can't be that hard there either
I'd imagine.

In fact, for most platforms (win32 + unices + os x) you can use our
libao cross platform audio library. It's job is to get raw audio out to
the speakers (or some fileformat like wav) on as many systems as
possible.

I might not be a bad idea or very difficult to add MacOS 9 support to
libao and just use that for all the interpreters. Or at least a simple
common implementation would be available.


And if you do use Ogg Vorbis, you'll get excellent quality and small
size. :)

jack.

PS. Greetings from the Ogg Vorbis team :)

dgr...@cs.csuabk.edu

unread,
Oct 8, 2001, 7:45:33 PM10/8/01
to

Unix Frotz will... kindof... almost... The graphics would also be rather
funny-looking.


--
David Griffith
dgr...@cs.csubak.edu

dgr...@cs.csuabk.edu

unread,
Oct 8, 2001, 7:51:48 PM10/8/01
to
Daniel Barkalow <iabe...@iabervon.org> wrote:

> I, at least, think that frotz is better-looking than glkterm, for the
> things it does. Considering the number of non-.blb glulx games in this
> comp, it seems like memory size and window-handling are useful enough
> without graphics and sound that this is worthwhile. It might be better,
> though, to write a frotz-based glk implementation, rather than glulx
> support for frotz.

I'm confused. Are you suggesting a glk implementation that uses Frotz's
low-level screen-handling techniques?


--
David Griffith
dgr...@cs.csubak.edu

OKB -- not okblacke

unread,
Oct 8, 2001, 8:16:34 PM10/8/01
to
ad...@fsf.net (Adam Thornton) wrote:
>*That*, it seems to me, is a job for the
>author--if a game plays OK on one full-on-multimedia terp, one
>terminal-only terp, and one stdio-only terp, then in an ideal world, it
>would be fair to assume it would work anywhere. The hard part is
>getting all the full-on terps to more or less agree on behavior.

Well, I can kind of see that, but I really think it would be great if we
could say "if a game works on one terp, it's safe to assume it works anywhere,
or tells you why". Now, maybe it won't have all the bells and whistles, or
indeed maybe it WON'T work, but if it doesn't work, the terp should say "I
can't handle this game because I don't support X, Y, and Z."

On one hand I feel like I'm asking for a lot, but on the other hand I also
feel like it's asking a lot to ask the author to test his game on all these
different platforms. I mean, isn't portability the whole Glk deal? What kind
of portability do we have if we have to keep second-guessing ourselves as to
whether it in fact IS portable?

Adam Thornton

unread,
Oct 9, 2001, 12:35:08 AM10/9/01
to
In article <anson-563176....@nntp.mindspring.com>,
Anson Turner <anson@DELETE_THISpobox.com> wrote:
>(Pardon the zeugma.)

As long as you wipe it up when you're done.

Adam

Torbjörn Andersson

unread,
Oct 9, 2001, 2:52:46 AM10/9/01
to
M Joonas Pihlaja <jpih...@cc.helsinki.fi> wrote:

> I like the availability of SONG format -- it allows the use of
> samples that aren't hardwired into the MOD. Not sure how well
> supported it is though.

The sound patches for XGlk that I've been involved with don't support
it at all. They define MOD as "whatever MikMod can handle". I don't
know how the other Glk implementations handle it though.

Torbjörn


Kent Tessman

unread,
Oct 9, 2001, 9:11:33 AM10/9/01
to
Sean T Barrett wrote:
> A number of platforms seem to offer a
> "here, I'll do all the work, you just tell me what to play and
> I'll play it" facility (windows provides this for playing videos
> and CDs and I assume for audio files), and those can be a real
> convenience to use for developers who don't have significant demands
> on it

>SIT IN CHAIR
You sit in the programmer's chair.

>WINDOWS, PLAY A SIMPLE VIDEO FILE
A hollow voice says, "Better get comfortable."

Daniel Barkalow

unread,
Oct 9, 2001, 11:47:19 AM10/9/01
to

Indeed, although it would probably be a pain to use that glk
implementation for anything other than inform-derived games, because it
would be restricted to a single buffer window in the middle, with optional
grid windows above and below, which makes sense for games with a status
line and maybe a menu at the bottom, but not for many other things.

But, despite the inherent limitations in the presentation, I really like
the windows bounded by reverse video rather than with a border that takes
up screen space. Not to mention the classic Infocom look and feel...

Andrew Plotkin

unread,
Oct 9, 2001, 12:57:55 PM10/9/01
to

In the GlkTerm library somewhere, there's an option to make textgrid
windows default to reverse video, and textbuffer windows to normal
text. I think. It was an attempt to provide Infocom-style display as
an option for Infocom-layout games, anyway.

David Kinder

unread,
Oct 9, 2001, 2:49:32 PM10/9/01
to
> The sound patches for XGlk that I've been involved with don't support
> it at all. They define MOD as "whatever MikMod can handle". I don't
> know how the other Glk implementations handle it though.

Windows Glk ignores it too. I use a very similar principle, i.e. define
MOD as "whatever ModPlug can handle" :)

David

David Kinder

unread,
Oct 9, 2001, 2:51:18 PM10/9/01
to
> play--which uses sox under the hood--reports
> sox: Bogus AIFF file: INSTrument but no MARKers.

Hmm, my decoder ignores both INST and MARK chunks. Oh well, time
to dig out the AIFF spec, I guess.

David

David Kinder

unread,
Oct 9, 2001, 2:56:25 PM10/9/01
to
> After the Comp, we (authors of various Glk libraries) will have a
> decent base of experience to actually make sound work right on
> them. :(

What we really need is a decent body of standard tests for Glk libraries.
You run the game, and if your library supports sound, you know what you
should here. Since AIFFs come as 8bit or 16bit there should be several
of these at different frequencies, etc. Every time someone comes up with
a variation that causes problems, it gets added to the standard test
harness.

We could also consider writing some sort of standard AIFF decoder that
could be shared across implementations that want to support it. This
shouldn't be that complicated and is something I'd prefer to using SDL,
which, while interesting, wasn't really good enough for production code
(at least not the last time I looked at it).

David

Andrew Plotkin

unread,
Oct 9, 2001, 3:19:42 PM10/9/01
to
David Kinder <D.Ki...@btinter-remove-to-reply-net.com> wrote:
>> After the Comp, we (authors of various Glk libraries) will have a
>> decent base of experience to actually make sound work right on
>> them. :(

> What we really need is a decent body of standard tests for Glk
> libraries.

That's part of what we need, but it comes after deciding what format
variations we are requesting and requiring.

> We could also consider writing some sort of standard AIFF decoder that
> could be shared across implementations that want to support it.

Yes.

At this point I know how to play raw sound streams on both MacOS and
Linux/FreeBSD. (Admittedly, the latter uses the OSS sound driver,
which is at the undesirable low layer of Unix sound protocol -- when
my code is running, it monopolizes the sound hardware. I ought to
rewrite it to use ESD, except that ESD is a pile of steaming rhino
apples, pardon my Uruguayan.)

Slapping a common AIFF decoder on top of that should be doable. If Ogg
Vorbis is solid enough to pick up these days, that can go in too. As
for MODs, um, I would prefer not to write one of those *too*; I guess
the question is whether we can find a MOD package whose license
doesn't put us in license hell.

> This
> shouldn't be that complicated and is something I'd prefer to using SDL,
> which, while interesting, wasn't really good enough for production code
> (at least not the last time I looked at it).

The earlier post said that SDL sound code would have to be rewritten
before it was really good, right, and that wasn't actaully on the
schedule yet?

Al Biggone

unread,
Oct 9, 2001, 9:48:47 PM10/9/01
to
ad...@fsf.net (Adam Thornton) wrote in message news:<9psv0g$2n4$2...@news.fsf.net>...

>It also happened on Big Al's Mac. I don't know its vintage or OS
level,
>however.

>Adam

Big Al, who is me, runs Mac OS 9.1 ( with QuickTime 5.0.2), on 1999's
top of the line G4 and regularly runs, for business purposes, every
possible graphics and sound resource-hogging program. Everything runs
fine on his, my, computer, except the sound in the game file Mr
Thornton discusses above. Oh, and he has no hope of running the Zeta
Space demo. The Glulx files that run well on his, my, computer are the
ones he beta-tests, or the ones I do.

From what little I remember about the discussion of how the sound
samples were made, however, it sounds like they were eight-bit samples
converted to sixteen-bit, which, depending on how it was done, might
not have solved the problem of the second eight bits being garbage (if
indeed this theory was true), if the garbage bits were converted too.
Okay, maybe that's not true. I don't know. I'm just trying to open the
possibility that it isn't a problem with the implementation of sound
support in the Glulx platform, in case it isn't.

But I don't know, do I?

Al

Torbjörn Andersson

unread,
Oct 10, 2001, 3:56:41 AM10/10/01
to
Andrew Plotkin <erky...@eblong.com> wrote:

> As for MODs, um, I would prefer not to write one of those *too*; I
> guess the question is whether we can find a MOD package whose license
> doesn't put us in license hell.

The only one I know of is MikMod. (I know of other libraries to play
MOD files, but they either use, or are based on, MikMod.) That doesn't
mean there aren't any others, of course. Just that I don't know of
them.

I don't know which licenses would be acceptable to you, but this is
what the MikMod README says:

The libmikmod sound library is covered by the GNU Library General
Public License as published by the Free Software Fundation (you'll
find it in the file COPYING.LIB) ; either version 2 of the licence,
or (at your option) any later version.

The GNU Lesser General Public License, version 2.1, in file
COPYING.LESSER, can be considered as a later version of the LGPL,
and is strongly recommended for people who will embed libmikmod in
their application as a shared library.

From what I've seen of MikMod, it's pretty nice to program with and is
quite well documented.

> The earlier post said that SDL sound code would have to be rewritten
> before it was really good, right, and that wasn't actaully on the
> schedule yet?

Apart from the bad frequency converter (which admittedly is a pretty
big "apart from"), the SDL sound patch seems to handle most of today's
Glulx games. (The only other sound-related problem I've seen is one of
the AIFF sounds in Carma, where it seems it couldn't find the sample
frequency. I haven't tried to find out why yet.)

It shouldn't be that difficult to add a better converter to SDL_sound,
but that won't be useful to us until SDL_mixer gets rewritten. Either
way, once that happens I plan on updating the SDL patch unless, of
course, a better solution has been found by then. As you say, there's
no schedule other than it being on Ryan's "TODO over time" list.

Torbjörn

David Kinder

unread,
Oct 10, 2001, 2:44:08 PM10/10/01
to
> The only one I know of is MikMod. (I know of other libraries to play
> MOD files, but they either use, or are based on, MikMod.) That doesn't
> mean there aren't any others, of course. Just that I don't know of
> them.

MikMod seems to work most of the time, but no-one seems to be actively
supporting it any more? On Windows I much prefer ModPlug, but that's
only available as a binary. Hmm, perhaps the author can be persuaded
to make a source release.

Actually, after typing this I've just done a Google search on ModPlug,
and on SourceForge there's something called "ModPlug XMMS Plugin",
based on ModPlug:

http://modplug-xmms.sourceforge.net/

I'll investigate this when I have time.

> I don't know which licenses would be acceptable to you, but this is
> what the MikMod README says:

That raises a point I'm not clear on, which also applies to the Ogg Vorbis
player Andrew mentioned: If you include an LGPL'd library in another
library (such as Glk), what restrictions does this place on the Glk
library itself?

From all this I think we need to be able to recommend a set of sound
libraries to Glk library authors, but I don't think that the Glk spec
should mandate the use of any of them.

David

Andrew Plotkin

unread,
Oct 10, 2001, 3:48:42 PM10/10/01
to
David Kinder <D.Ki...@btinter-remove-to-reply-net.com> wrote:

> That raises a point I'm not clear on, which also applies to the Ogg Vorbis
> player Andrew mentioned: If you include an LGPL'd library in another
> library (such as Glk), what restrictions does this place on the Glk
> library itself?

That's sort of fuzzy. A modification of the LGPL library is a derived
work, and must be LGPL. However, I think it's considered okay to
distribute a package containing an LGPL module and a non-LGPL module, as
long as they're separable, and the LGPL piece is a complete library on
its own.

I'd be willing to distribute Glk libraries this way. A program linking
it would have to consider that it was linking an LGPL library and some
other library, at the same time.

> From all this I think we need to be able to recommend a set of sound
> libraries to Glk library authors, but I don't think that the Glk spec
> should mandate the use of any of them.

No. But it certainly looks like -- at least for AIFF and MOD -- if
most ports use a particular sound library, all ports will have to
either use that library or do a lot of work/testing to be compatible
with that library.

For Ogg Vorbis, as far as I know, there *is* only one decoder library.

Dylan Thurston

unread,
Oct 11, 2001, 6:22:00 AM10/11/01