Glk and Glulx
dgr...@cs.csuabk.edu
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
}
}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
> 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
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
> 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
>}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
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
<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
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
>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
>Let's take--as a purely random example, not one that I ever would have
>encountered or anything--AIFF sound.
>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
> 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
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
> 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
> 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
> (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
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
>> 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
>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
> 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
> 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
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
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
>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
> 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
>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
Matthew T. Russotto
}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
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
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
>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
>
>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
>>
>>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
>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
>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
>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
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
> 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
In theory, Nitfol. In practice, I'm not sure. The blorb
file is optional.
Sean T Barrett
>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
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
> 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
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
> 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
Unix Frotz will... kindof... almost... The graphics would also be rather
funny-looking.
--
David Griffith
dgr...@cs.csubak.edu
dgr...@cs.csuabk.edu
> 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
>*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
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
> 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
> 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
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
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
> 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
> 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
> 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
>> 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
>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
> 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
> 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
> 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
>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.
This is certainly within the intended use of the LGPL, and pretty clearly
allowed by the license, as long as you have working shared libraries.
MacMikMod and the original MikMod for DOS both seem to be dead.
I did a quick search for free MOD players in Debian, and found:
xmms-modplug and xmp - both GPL
s3mod - no restrictions
No idea how good they are. I probably missed some.
Best,
Dylan Thurston
Torbjörn Andersson
> MacMikMod and the original MikMod for DOS both seem to be dead.
I've read that the Mac version at http://www.mikmod.org doesn't work.
Is the one at http://www.algonet.se/~afb/mikmod/ broken as well?
I don't know anything about a DOS version, sorry.
Torbjörn
Joe Mason
Andrew Plotkin <erky...@eblong.com> wrote:
>> 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...
>
>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.
-revgrid yes -border no
Joe
Joe Mason
Andrew Plotkin <erky...@eblong.com> wrote:
>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.
If you link with GlkLoader, which loads libraries by dynamically, the whole
license problem more or less goes away.
Actually, the question of how dynamic loading or embedded componentes or
whatever count interacts with the GPL is a pretty tricky one. In this
case, though, if a Glk-using program (say nitfol, GPL) is linked with
GlkLoader (BSD license), that's clearly legal. And if an end-user were to
then download MSGlk (proprietary) and load it with GlkLoader, that doesn't
violate the GPL unless said end-user distributes the package, even under the
most restrictive reading. (If the *only* purpose of GlkLoader were to
load proprietary libraries, that'd be unethical if not actually illegal. But
GlkLoader can also be used to load CheapGlk and XGlk, which are under
GPL-compatible licenses IIRC.)
(The question was about the LGPL, but the GPL is more restrictive so it makes
a better example.)
Joe
Magnus Olsson
OKB -- not okblacke <bren...@aol.comRemove> wrote:
> 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.
A somewhat related issue: I'd like the terp to tell the program it's running
whether a style hint was taken or not.
Suppose my game wants to use italics, and sets a style hint that
emphasized text should be shown as italic. The terp is free to ignore
the hint, but it would be nice if the program could have some way
of knowing that.
Alternatively, there should be a way for the program to see how a
certain style is actullay displayed.
A rather trivial example: The program wants to tell the user that
emphasized words are important, so it prints the text "words that
appear in italics can be looked up in the dictionary". However,
the terp may display emphasized text as bold, or underlined, and
in that case the word "italics" should be changed accordingly.
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
Andrew Plotkin
> A somewhat related issue: I'd like the terp to tell the program it's running
> whether a style hint was taken or not.
glk_style_distinguish(), glk_style_measure().
Yes, it would be better if you could test the style *before* opening
the window. This will be dealt with eventually.
Matthew T. Russotto
Joe Mason <jcm...@student.math.uwaterloo.ca> wrote:
}
}Actually, the question of how dynamic loading or embedded componentes or
}whatever count interacts with the GPL is a pretty tricky one. In this
}case, though, if a Glk-using program (say nitfol, GPL) is linked with
}GlkLoader (BSD license), that's clearly legal. And if an end-user were to
}then download MSGlk (proprietary) and load it with GlkLoader, that doesn't
}violate the GPL unless said end-user distributes the package, even under the
}most restrictive reading. (If the *only* purpose of GlkLoader were to
}load proprietary libraries, that'd be unethical if not actually illegal. But
}GlkLoader can also be used to load CheapGlk and XGlk, which are under
}GPL-compatible licenses IIRC.)
Stallman seems to think that a program which uses a GPLed (not LGPLed)
shared library must be GPLed to be distributed even if it is
distributed without the shared library. I don't think he's got a leg
to stand on there, personally, not unless he wants to give up his
claim that the GPL does not go beyond copyright. I'm not sure if
dynamic shared libraries are considered separately from staticly
linked ones for those purposes.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Daniel Barkalow
> Stallman seems to think that a program which uses a GPLed (not LGPLed)
> shared library must be GPLed to be distributed even if it is
> distributed without the shared library. I don't think he's got a leg
> to stand on there, personally, not unless he wants to give up his
> claim that the GPL does not go beyond copyright. I'm not sure if
> dynamic shared libraries are considered separately from staticly
> linked ones for those purposes.
I believe that he is looking askance at programs that require a GPLed
library, not ones where there happens to be a GPL version of something it
uses. The difference is mainly if you're distributing a product that
doesn't actually do anything, and can't be made to do anything without
linking with a GPLed library, and saying that it's not worthless; that
would be a bit like selling a book jacket for holding together a set of
photocopies of pages of someone else's book, and pretending that you were
selling a book. But in any case, if you take someone else's fully-formed
program, and link it to a GPLed library, you may not be able to distribute
it, but you can use it, and the other person can continue to distribute
their program.
David Kinder
> xmms-modplug and xmp - both GPL
> s3mod - no restrictions
These all need investigating - it would be good to see which play
all the mods in Zeta Space (I suspect only ModPlug is the answer,
but it's good to check).
David
Matthew T. Russotto
Daniel Barkalow <iabe...@iabervon.org> wrote:
}On Fri, 12 Oct 2001, Matthew T. Russotto wrote:
}
}> Stallman seems to think that a program which uses a GPLed (not LGPLed)
}> shared library must be GPLed to be distributed even if it is
}> distributed without the shared library. I don't think he's got a leg
}> to stand on there, personally, not unless he wants to give up his
}> claim that the GPL does not go beyond copyright. I'm not sure if
}> dynamic shared libraries are considered separately from staticly
}> linked ones for those purposes.
}
}I believe that he is looking askance at programs that require a GPLed
}library, not ones where there happens to be a GPL version of something it
}uses.
I don't really think it makes a difference in terms of violating the
GPL. If I make a program which links to libfoo.so, where there's both
GPL and non-GPL versions of libfoo extant, Stallman claims that anyone
linking my proprietary program to the GPL libfoo.so is violating the
GPL. Linking a GPL main to a proprietary shared library that isn't
part of the OS is the same thing. So if you link Nitfol (GPL) with the
theoretical proprietary MSGlk, you've violated the GPL in Stallman's
eyes. I don't think he's got a leg to stand on, but I'm sure the FSF
has better lawyers than I do.
BTW, I checked, and his view on dynamicly-loaded shared libraries (plug-ins) is
the same as on ordinary ones. This means using GlkLoader as an
intermediary doesn't save you.
OKB -- not okblacke
>A somewhat related issue: I'd like the terp to tell the program it's running
>whether a style hint was taken or not.
>Alternatively, there should be a way for the program to see how a
>certain style is actullay displayed.
Yes. I'd really like to have both of these -- the second could be used to
see what the default display settings are, if nothing else.
L. Ross Raszewski
>Magnus Olsson <m...@df.lth.se> wrote:
>
>> A somewhat related issue: I'd like the terp to tell the program it's running
>> whether a style hint was taken or not.
>
>glk_style_distinguish(), glk_style_measure().
>
>Yes, it would be better if you could test the style *before* opening
>the window. This will be dealt with eventually.
Now, as I understand it, however, there are some hints for which the
process of determining what effect the stylehint had is nontrivial;
From memory, I think I recall that the font size stylehint suggests a
relative scaling; you give how much bigger or smaller you want the
font to be from whatever is default (assuming +-1 to be "the smallest
unit of change which is clearly visible and covnenient to the
interpreter"), whereas the font size measurement returns the size of
the font in "Whatever unit is convenient for the interpreter". Not
that it's impossible to work out whether or not the hint did
*something*, but it can be quite difficult, if I'm remembering
correctlyy, to work out exactly *what* effect the hint had.
Torbjörn Andersson
> These all need investigating - it would be good to see which play
> all the mods in Zeta Space (I suspect only ModPlug is the answer,
> but it's good to check).
Hmm... Is there a ModPlug library to link with under UNIX, though? All
I can find is a ModPlug DLL for Windows and the XMMS plugin for Linux,
and I'm not sure if/how Glk could use that.
(For what it's worth, MikMod 3.1.9 does handle all the MODs in Zeta
Space, while 3.1.8 fails on some.)
Torbjörn
Matthew T. Russotto
L. Ross Raszewski <lrasz...@loyola.edu> wrote:
}On Mon, 8 Oct 2001 20:32:41 +0000 (UTC), Adam Thornton <ad...@fsf.net> wrote:
}>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
}
}In theory, Nitfol. In practice, I'm not sure. The blorb
}file is optional.
Nitfol on the Mac does work. Sort of. The display is pretty bad.
Andrew Plotkin
It's obviously impossible to determine the physical size on the screen
of displayed text -- particularly for GlkTerm and other
virtual-terminal interpreters. But even for GUI interpreters it's
tricky, given the mess that is font-size conventions and resolution
conventions these days.
I see what you mean about not being able to connect the output (in
pixels, font units, or whatever) back to the original relative scaling
factor. Should both be available? Would anybody miss the current
output format if it went away?
David Kinder
> I can find is a ModPlug DLL for Windows and the XMMS plugin for Linux,
> and I'm not sure if/how Glk could use that.
I think we'd have to do some coding to get it going. However, since the
XMMS plugin is LGPLd, I guess it could be modified to meet our needs.
> (For what it's worth, MikMod 3.1.9 does handle all the MODs in Zeta
> Space, while 3.1.8 fails on some.)
That's worth knowing. So is MikMod still actively supported?
David
Marnie Parker
on/off, i.e. currently running.
And a get window child function. And get window parent function that returns a
useable value (such as useable in Inform). Or a function that returns in what
order windows were opened. Something like that.
Doe :-) Since we are wishing.
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/
L. Ross Raszewski
Well... I think that any game that uses the metric for font size in a
non-trivial way (ie. "Check it now. Create a window using the
hint. Check it again. See if they're equal") is very likely to be
making a nonportable assumption of the sort we've been discussing for
the past week (ie. "Hm. It returned 10. THat means 10 point, which is
a quarter of an inch tall on the player's screen"), so it probably
won't hurt to drop the old value.
Colors are another area of some concern. In GlkDOS, for instance, text
colors are dithered to the nearest 4-bit color. GlkDOS correctly
identifies the color it's actually using when asked abotu the color of
a style. Of course, an author will have to understand that a hint can
have three possible effects: The hint had no effect; THe hint did what I
intended; The hint was accepted, but its ultimate effect was not
exactly what I requested. This must, of course, be done by the
author, and not Glk, but it's something that people have ot consider
when using style hints. Far too often, I think, authors are liable to
forget that hints are just that -- hints; you tell the interpreter
what you want, and if it listens to you at all, it will give you "as
close as it can conveniently get" to the requested effect.
A color-related issue of some particular concern to me: GlkDOS renders
boldface by turning on the high-intensity bit in its internal 4-bit
color model. I don't actually recall whether asking about the color of
a bold style will give the intense or nonintense version of the color,
and I'm not sure which it should do. I think, though, I was clever
enough to have glk_style_distinguish recognize that bright color x, is
indistinguishable from dim color x in boldface.
Andrew Plotkin
> It would also be nice to have a routine to test if the glk timer is currently
> on/off, i.e. currently running.
That falls into the "you set it -- you can keep track" category. Which
is not an attempt at laziness, but my assertion that it's better to
integrate this sort of thing into a complete package at the Inform
library level, rather than passing data constantly into and out of the
Glk layer.
One accessor is easy; adding accessors for every possible piece of Glk
state would add a large burden to the libraries, which may be relying
on native OS mechanisms for a lot of this stuff.
> And a get window child function.
Hm, possibly. (Just because I've got get_parent now.)
> And get window parent function that returns a
> useable value (such as useable in Inform).
It returns a window identifier, same as every other window identifier
used in Inform.
> Or a function that returns in what
> order windows were opened. Something like that.
That's *definitely* in the category of "if you care, you should keep
track."
Adam Thornton
Andrew Plotkin <erky...@eblong.com> wrote:
>I see what you mean about not being able to connect the output (in
>pixels, font units, or whatever) back to the original relative scaling
>factor. Should both be available? Would anybody miss the current
>output format if it went away?
Which output format?
If you mean the ability to specify a picture's size in pixels within
glk, yes, I would miss that, as the way I do scrolling depends on it.
Adam
Dylan Thurston
>I don't really think it makes a difference in terms of violating the
>GPL. If I make a program which links to libfoo.so, where there's both
>GPL and non-GPL versions of libfoo extant, Stallman claims that anyone
>linking my proprietary program to the GPL libfoo.so is violating the
on use in the GPL or LGPL.
>GPL.
If you mean static linking, yes, that's right, and true: you are
distributing a copy of libfoo.so without a license. I don't think
there's much argument there.
If you mean dynamic linking, I do not believe that this is Stallman's
view. Can you give a reference?
Stallman seems to believe that if there are _only_ GPL versions of libfoo.so,
any program that uses libfoo is a derived work of libfoo, whether
distributed with libfoo or not.
Yes, this leads to some silly situations, and some people disagree.
But this is quite off-topic, especially since libmikmod is LGPL
which was specifically crafted to allow this.
--Dylan Thurston
Dylan Thurston
>> Hmm... Is there a ModPlug library to link with under UNIX, though? All
>> I can find is a ModPlug DLL for Windows and the XMMS plugin for Linux,
>> and I'm not sure if/how Glk could use that.
>I think we'd have to do some coding to get it going. However, since the
>XMMS plugin is LGPLd, I guess it could be modified to meet our needs.
Please note the distinction between the LGPL and the GPL. AFAIK, the
XMMS plugin is GPLd, which might be a more controversial choice.
But you could also ask the author.
>> (For what it's worth, MikMod 3.1.9 does handle all the MODs in Zeta
>> Space, while 3.1.8 fails on some.)
>
>That's worth knowing. So is MikMod still actively supported?
3.1.9 was released February 2000, but they've been updating their web
page recently.
--Dylan Thurston
Matthew T. Russotto
Dylan Thurston <d...@abel.math.harvard.edu> wrote:
}In article <eLHx7.207$fe.3...@newshog.newsread.com>, Matthew T. Russotto wrote:
}>I don't really think it makes a difference in terms of violating the
}>GPL. If I make a program which links to libfoo.so, where there's both
}>GPL and non-GPL versions of libfoo extant, Stallman claims that anyone
}>linking my proprietary program to the GPL libfoo.so is violating the
} ^^^ insert "and distributing" here: there are no restrictions
} on use in the GPL or LGPL.
I agree with you, but Stallman thinks not.
http://www.fsf.org/licenses/gpl-faq.html
Look at the questions on plug-ins. I say he's full of shit and that
if I make a non-free plug-in for a GPLed program, I'm fine and there's
nothing the GPL could do about it even if Stallman wanted it to.
Using a plug-in interface is not the same as creating a derivative
work (and the FSF really doesn't want it to be).
}Stallman seems to believe that if there are _only_ GPL versions of libfoo.so,
}any program that uses libfoo is a derived work of libfoo, whether
}distributed with libfoo or not.
He never makes the distinction between libraries which only exist in
GPLed form and those which don't. Such a distinction would be silly.
And his position is silly as well. If I distribute a proprietary work which
requires but does not include a GPLed library, it doesn't contain any
code covered by the GPL, and thus cannot be a derivative work. You
could make the argument that when the user brings together the GPLed
library and the proprietary work, he's creating a derivative work --
but as you point out, the GPL does not restrict creation of such a
work.
}Yes, this leads to some silly situations, and some people disagree.
}
}But this is quite off-topic, especially since libmikmod is LGPL
}which was specifically crafted to allow this.
But Nitfol is not, so the idea of a Glk library distributed with a
GPL-incompatible license could come up.
Joe Mason
Matthew T. Russotto <russ...@wanda.vf.pond.com> wrote:
>I don't really think it makes a difference in terms of violating the
>GPL. If I make a program which links to libfoo.so, where there's both
>GPL and non-GPL versions of libfoo extant, Stallman claims that anyone
>linking my proprietary program to the GPL libfoo.so is violating the
>GPL. Linking a GPL main to a proprietary shared library that isn't
No he doesn't.
The GPL says (GPL-2.0, section 0, paragraph 2):
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
I can do whatever I want with my GPL'd program, including link it to
commercial programs, in the privacy of my own home. I just can't distribute
it unless it meets the conditions of the GPL, because that would break the
author's copyright.
Since this is the whole basis for Stallman's copyleft idea, you'd have to
give me some pretty solid references to convince me that he said what you
claim. (And if you convince me, I'll laugh at him and call him insane.)
Joe
Joe Mason
>}>GPL and non-GPL versions of libfoo extant, Stallman claims that anyone
>}>linking my proprietary program to the GPL libfoo.so is violating the
>} ^^^ insert "and distributing" here: there are no restrictions
>} on use in the GPL or LGPL.
>
>I agree with you, but Stallman thinks not.
>http://www.fsf.org/licenses/gpl-faq.html
>
>Look at the questions on plug-ins. I say he's full of shit and that
Er, the question on plugins doesn't mention anything about distributing or
not. Did you mean the one right below it, where he says:
You have a GPL'ed program that I'd like to link with my code to build a
proprietary program. Does the fact that I link with your program mean I
have to GPL my program?
Yes.
If so, it's pretty clear he's assuming the proprietary program will be
distributed. A few sentences later, he says:
... the idea of
the GPL is that if you want to include our code in your program, your
program must also be free software. It is supposed to put pressure on
you to release your program in a way that makes it part of our
community..
If you're not releasing it, that reasoning wouldn't come into play.
>if I make a non-free plug-in for a GPLed program, I'm fine and there's
>nothing the GPL could do about it even if Stallman wanted it to.
>Using a plug-in interface is not the same as creating a derivative
>work (and the FSF really doesn't want it to be).
I'm not arguing for or against this - it's a huge grey area they I don't
want to get involved in. I'm just saying that even if Stallman is correct,
we can sidestep the whole issue by using GlkLoader.
Joe
Matthew T. Russotto
Joe Mason <jcm...@student.math.uwaterloo.ca> wrote:
}In article <eLHx7.207$fe.3...@newshog.newsread.com>,
}Matthew T. Russotto <russ...@wanda.vf.pond.com> wrote:
}>I don't really think it makes a difference in terms of violating the
}>GPL. If I make a program which links to libfoo.so, where there's both
}>GPL and non-GPL versions of libfoo extant, Stallman claims that anyone
}>linking my proprietary program to the GPL libfoo.so is violating the
}>GPL. Linking a GPL main to a proprietary shared library that isn't
}
}No he doesn't.
}
}The GPL says (GPL-2.0, section 0, paragraph 2):
}Since this is the whole basis for Stallman's copyleft idea, you'd have to
}give me some pretty solid references to convince me that he said what you
}claim. (And if you convince me, I'll laugh at him and call him insane.)
Read the GPL FAQ (which IMO contradicts the GPL). Yes, he's insane.
http://www.fsf.org/licenses/gpl-faq.html#GPLPluginsInNF
http://www.fsf.org/licenses/gpl-faq.html#GPLAndPlugins
http://www.fsf.org/licenses/gpl-faq.html#LinkingWithGPL
L. Ross Raszewski
Loophole 01:
That a program is GPL does not require that anyone distribute it. If I
want to write a program that uses a GPL library, I do so. THe program
is GPL. THis doesn't mean a wet slap to me, because I'm not
distributing it.
Now, let's cleverly apply this backwards. You write a program that
requires a GPL library to run. You don't link the program with a GPL
library. You release the program on your own terms. WHen a user links
the program with a GPL library to run it, the program becomes GPL. But
only the version he's running is GPL, and he isn't goign to distribute
it.
Well. It might work. GPL is a very strange and infectious disease.
Andrew Plotkin
> In article <9q9nbn$ini$1...@news.panix.com>,
> Andrew Plotkin <erky...@eblong.com> wrote:
>>I see what you mean about not being able to connect the output (in
>>pixels, font units, or whatever) back to the original relative scaling
>>factor. Should both be available? Would anybody miss the current
>>output format if it went away?
> Which output format?
The output of glk_measure_style when asked about font size.
> If you mean the ability to specify a picture's size in pixels within
> glk, yes, I would miss that, as the way I do scrolling depends on it.
No, the size of pictures will always be related to the size of
graphics windows in the expected way.
Daniel Barkalow
> In article <Pine.LNX.4.21.011012...@iabervon.org>,
> Daniel Barkalow <iabe...@iabervon.org> wrote:
> }On Fri, 12 Oct 2001, Matthew T. Russotto wrote:
> }
> }> Stallman seems to think that a program which uses a GPLed (not LGPLed)
> }> shared library must be GPLed to be distributed even if it is
> }> distributed without the shared library. I don't think he's got a leg
> }> to stand on there, personally, not unless he wants to give up his
> }> claim that the GPL does not go beyond copyright. I'm not sure if
> }> dynamic shared libraries are considered separately from staticly
> }> linked ones for those purposes.
> }
> }I believe that he is looking askance at programs that require a GPLed
> }library, not ones where there happens to be a GPL version of something it
> }uses.
>
> I don't really think it makes a difference in terms of violating the
> GPL. If I make a program which links to libfoo.so, where there's both
> GPL and non-GPL versions of libfoo extant, Stallman claims that anyone
> linking my proprietary program to the GPL libfoo.so is violating the
> GPL.
"Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope."
Linking is none of these; running a program is specifically excluded from
the scope of the license. Presumably, neither of these requires a license,
in the FSF's interpretation, or running Linux would be illegal, since
there's not an additional license for it. The FSF, as a general rule,
sides with users over producers of software, and would be highly unlikely
to restrict what an end user can do.
If you link GPL code and proprietary code, you can't then distribute the
result, but you can use it yourself. If you link GPL code and proprietary
code, then unlink it, distribute the proprietary code, and tell your
customers to relink it with GPLed code, he thinks you're violating the
license (you sort of have the GPLed interface, in negative, imprinted on
your code). But if you distribute code which could be linked against GPLed
code, or against your proprietary code, or against some other code, that's
fine for you to do, and he won't bother people who just link it and use it
themselves.
> Linking a GPL main to a proprietary shared library that isn't
> part of the OS is the same thing. So if you link Nitfol (GPL) with the
> theoretical proprietary MSGlk, you've violated the GPL in Stallman's
> eyes. I don't think he's got a leg to stand on, but I'm sure the FSF
> has better lawyers than I do.
If you do this, and just keep it and use it yourself, he doesn't mind; in
fact, he's probably glad you're not using MSZMachine, although he would
encourage you to use a GPLed Glk as well, if possible. It would be very
much out of character for him to try to force someone to use proprietary
software when a GPL alternative exists.
On the other hand, if you distribute your Nitfol linked against MSGlk,
he'll be upset at you.
Matthew T. Russotto
Daniel Barkalow <iabe...@iabervon.org> wrote:
}On Fri, 12 Oct 2001, Matthew T. Russotto wrote:
}>
}> I don't really think it makes a difference in terms of violating the
}> GPL. If I make a program which links to libfoo.so, where there's both
}> GPL and non-GPL versions of libfoo extant, Stallman claims that anyone
}> linking my proprietary program to the GPL libfoo.so is violating the
}> GPL.
}
}"Activities other than copying, distribution and modification are not
} covered by this License; they are outside its scope."
}
}Linking is none of these; running a program is specifically excluded from
}the scope of the license.
Linking involves both copying and modifying.
}there's not an additional license for it. The FSF, as a general rule,
}sides with users over producers of software, and would be highly unlikely
}to restrict what an end user can do.
Indeed, I believe Stallman is being inconsistent.
}result, but you can use it yourself. If you link GPL code and proprietary
}code, then unlink it, distribute the proprietary code, and tell your
}customers to relink it with GPLed code, he thinks you're violating the
}license (you sort of have the GPLed interface, in negative, imprinted on
}your code).
Right. And I say I'm not, and cannot be, because my proprietary code
is not subject to his license. Use of someone else's interface does
not require a license except in Microsoft's dreams. And in his
plug-in section, he tries to claim that not just the distribution of
linked code, but the linking itself, is covered: "This means that
linking the GPL-covered plug-in with the [non-free] main program would
violate the GPL."
Daniel Barkalow
> In article <9qabas$pib$1...@watserv3.uwaterloo.ca>,
> Joe Mason <jcm...@student.math.uwaterloo.ca> wrote:
> }In article <eLHx7.207$fe.3...@newshog.newsread.com>,
> }Matthew T. Russotto <russ...@wanda.vf.pond.com> wrote:
> }>I don't really think it makes a difference in terms of violating the
> }>GPL. If I make a program which links to libfoo.so, where there's both
> }>GPL and non-GPL versions of libfoo extant, Stallman claims that anyone
> }>linking my proprietary program to the GPL libfoo.so is violating the
> }>GPL. Linking a GPL main to a proprietary shared library that isn't
> }
> }No he doesn't.
> }
> }The GPL says (GPL-2.0, section 0, paragraph 2):
>
> }Since this is the whole basis for Stallman's copyleft idea, you'd have to
> }give me some pretty solid references to convince me that he said what you
> }claim. (And if you convince me, I'll laugh at him and call him insane.)
>
> Read the GPL FAQ (which IMO contradicts the GPL). Yes, he's insane.
>
> http://www.fsf.org/licenses/gpl-faq.html#GPLPluginsInNF
> http://www.fsf.org/licenses/gpl-faq.html#GPLAndPlugins
> http://www.fsf.org/licenses/gpl-faq.html#LinkingWithGPL
I belive that those only really apply under the case where the program
defines the plug-in interface. The glk interface is defined by something
with a GPL-compatible, other-stuff-compatible, license. Libraries of all
sorts are linked against this interface, essentially; programs are
similarly linked against it. The glk library isn't a plug-in to Nitfol,
it's essentially a plug-in to glk.h; similarly, Nitfol is a plug-in to
glk.h, since it doesn't depend on the library on the other side.
In any case, if everything distributed is usable with something with a
compatible license, the distributors are safe. So long as they only use
the program, the users are always safe (at least, wrt the FSF). So the
only situation is that you couldn't link the programs in certain
combinations and distribute the results.
Mike Roberts
> Indeed, I believe Stallman is being inconsistent.
> Use of someone else's interface does not require a license
> except in Microsoft's dreams. And in his plug-in section,
> he tries to claim that not just the distribution of linked code,
> but the linking itself, is covered: "This means that linking the
> GPL-covered plug-in with the [non-free] main program
> would violate the GPL."
I ran into this same issue recently in the context of porting html tads to
unix using a GPL'd windowing library, and I had exactly the same reaction as
you - it seems egregiously overreaching to try to assert control over use of
a dynamically-linked interface by invoking the copyright on an
implementation of that interface. At a technical level, there is simply no
justification for this position: it is technically equivalent to saying that
you cannot port the program to Windows, because Windows is not under GPL and
so its invocation of the GPL'd code's main() routine (the world's original
plug-in interface) would be illegal.
Nonetheless, despite my frustration that Stallman's position is so poorly
reasoned technically, I respect the rights of developers using GPL to
control the use of their work, and I grudgingly accept that Stallman's
position on dynamic linking is consistent with the spirit of his licensing
terms. In the specific case of the unix windowing library of which I spoke,
it's especially irritating because they're using the infectiousness of the
GPL terms as a club to sell their $4000 "professional" version, which is the
same software with less restrictive licensing terms - this strikes me as
contrary to the spirit of the GPL, but again, I respect their right to
control their work as they see fit.
--Mike
mjr underscore at hotmail dot com
Evin Robertson
> In article <Pine.LNX.4.21.011016...@iabervon.org>,
> Daniel Barkalow <iabe...@iabervon.org> wrote:
>}there's not an additional license for it. The FSF, as a general
>}rule, sides with users over producers of software, and would be
>}highly unlikely to restrict what an end user can do.
>
> Indeed, I believe Stallman is being inconsistent.
I don't think Stallman is as crazy (on this issue) as you picture him
-- the FAQ was written for the common case of one unique application,
one unique library.
From http://www.cs.uni-magdeburg.de/~aschultz/mico/mico-devel/1997-11/msg00015.html
Richard Stallman wrote:
> There is no fundamental difference between static and dynamic linking,
> as regards the GNU GPL or the GNU LGPL. Our position is that if you
> link a GNU program into a combined program, no matter what kind of
> linking you use, you have to obey the terms of the GNU program in
> distributing the combination.
Note the "distributing" and "combination" bits.
One of the freedoms Stallman celebrates is the right to do whatever
you want privately (with regard to software). He declares licenses
which public disclosure of private modification "nonfree." No one has
been granted any license to code you write privately, so that code is
proprietary, yet Stallman demands we have the right to code as such.
It's quite possible you're correct, but I don't think it's clear just
from that FAQ.
>}result, but you can use it yourself. If you link GPL code and
>}proprietary code, then unlink it, distribute the proprietary code,
>}and tell your customers to relink it with GPLed code, he thinks
>}you're violating the license (you sort of have the GPLed interface,
>}in negative, imprinted on your code).
>
> Right. And I say I'm not, and cannot be, because my proprietary code
> is not subject to his license. Use of someone else's interface does
> not require a license except in Microsoft's dreams. And in his
> plug-in section, he tries to claim that not just the distribution of
> linked code, but the linking itself, is covered: "This means that
> linking the GPL-covered plug-in with the [non-free] main program would
> violate the GPL."
If the only way your program can run is by (dynamically) linking to a
GPL library, and you distribute the two together, it's clear that the
combination is a derivative work. The reasoning is that distributing
them seperately (or your manual reading "go to ftp://www.gnu.org/") is
merely a way of sidestepping the license and doesn't dissolve your
obligation.
The GNU reasoning is that if dynamic linking is permitted without
restriction, the the GPL has no teeth. Want to add (and sell) a
nonfree extension to GCC? Just add some hooks in it to call your
binary-only libraries. And the users end up chained to nonfree
software while still using GCC.
However, I agree with you that it doesn't make any sense. I could,
using the readline documentation, write and distribute code which uses
it without ever having seen the readline libraries themselves (if it
compiles, ship -- don't worry about link errors :). It doesn't make
any sense that what I wrote is a derivative of the readline library
and must be subject to its license. Other people have noted the
arbitrary distinction between the syscall/exec/pipe and linking
interfaces. They essentially accomplish the same thing, and indeed
people have written wrappers for readline so you don't have to
actually link to it...
In the case of Glk, it's clearly silly to say that libraries must be
GPL-compatible just because nitfol exists. I certainly would not
object to people *running* nitfol with nonfree Glk libraries. But if
you distribute nitfol linked to that library, I would (and have).
GlkLoader wouldn't make any difference. If you added extra hooks to
nitfol to take advantage of Super-Secret-Stuff only available in a
nonfree library, I'd also object.
Enough of that. Meanwhile, I go back to figuring out how to get smtuc
to behave with Arrange events in my GtkGlk (LGPL). I don't know how
to distinguish between resize events generated by the user or by the
program -- Gtk says "This widget has been resized. Draw something
there." smtuc splits a window, so against the Glk spec, I generate an
Arrange event. Doing the only thing it can to violate my
sensibilities, smtuc closes and resplits its windows, causing Gtk to
generate resize events, causing...
Joe Mason
>} covered by this License; they are outside its scope."
>}
>}Linking is none of these; running a program is specifically excluded from
>}the scope of the license.
>
>Linking involves both copying and modifying.
So? It involves copying it around on your own computer.
As long as you don't give the code to anybody else, *IT DOESN'T MATTER*.
>}result, but you can use it yourself. If you link GPL code and proprietary
>}code, then unlink it, distribute the proprietary code, and tell your
>}customers to relink it with GPLed code, he thinks you're violating the
>}license (you sort of have the GPLed interface, in negative, imprinted on
>}your code).
>
>Right. And I say I'm not, and cannot be, because my proprietary code
>is not subject to his license. Use of someone else's interface does
Ok, whatever. You've made that point several times. Nobody's arguing with
you - all we've done is state Stallman's claims. If you disagree, take it
up with him.
Joe
Branko Collin
-0700:
>Matthew T. Russotto wrote:
>> In article <Pine.LNX.4.21.011016...@iabervon.org>,
>> Daniel Barkalow <iabe...@iabervon.org> wrote:
>>}result, but you can use it yourself. If you link GPL code and
>>}proprietary code, then unlink it, distribute the proprietary code,
>>}and tell your customers to relink it with GPLed code, he thinks
>>}you're violating the license (you sort of have the GPLed interface,
>>}in negative, imprinted on your code).
>>
>> Right. And I say I'm not, and cannot be, because my proprietary code
>> is not subject to his license. Use of someone else's interface does
>> not require a license except in Microsoft's dreams. And in his
>> plug-in section, he tries to claim that not just the distribution of
>> linked code, but the linking itself, is covered: "This means that
>> linking the GPL-covered plug-in with the [non-free] main program would
>> violate the GPL."
>
>If the only way your program can run is by (dynamically) linking to a
>GPL library, and you distribute the two together, it's clear that the
>combination is a derivative work. The reasoning is that distributing
>them seperately (or your manual reading "go to ftp://www.gnu.org/") is
>merely a way of sidestepping the license and doesn't dissolve your
>obligation.
As it happens, I have been thinking about this matter for a while now.
As a non-programming member of the GIMP community
(<http://www.gimp.org>) I took it upon myself to make sure our license
situation is correct. The GIMP is a complex package and allows several
kinds of plug-in. I wrote to lice...@gnu.org with several questions,
because the GPL and the GPL-FAQ were not very clear.
I reprint my correspondence here verbatim, as I feel that the text
would undoubtedly loose something in paraphrasing.
GNU:
> Branko:
> > GNU:
> > > Branko:
> > > > 2) The GIMP uses an interpreted macro language, Scheme.
> > > > The interpreter itself is a plug-in to the main program.
> > > > All plug-ins, macros and the functions of the program
> > > > itself are available to each other. Their interface
> > > > takes the shape of a function call which returns values
> > > > and which you can pass values. This makes for a very
> > > > powerful system, because you can use every available
> > > > tool from every other tool. My question: does this make
> > > > scripts an integral part of the GIMP (to be GPL'ed) or
> > > > do the scripts remain independent programs? You may have
> > > > encountered similar questions with systems that use an
> > > > Inter Proces Language, such as the Amiga OS with ARexx.
> > >
> > > If the scripts are derivative works of the GIMP, they must
> > > be released under the GPL. For example, calling internal
> > > GIMP functions (such as gimp_layer_new) would make scripts
> > > derivative of the GIMP.
> >
> > Surely, using function calls does not constitute a
> > derivative work? I thought that if the scripts were also
> > covered by the GPL, this would be because they are part of
> > the work, not because they are derived from it.
>
> Well, the function calls don't, but linking against the GIMP
> library does, because parts of the library are included in the
> source. Also, including the GPL'd headers makes the program a
> derivative work.
>
> > > The GIMP authors may choose to make a special exception
> > > for these scripts, but as far as I know, they have not.
> >
> > Indeed we have not. (As in many free software projects,
> > 'the authors' is a nebulous entity.)
> >
> > The question is: does it matter wether a plug-in is part of
> > the distribution or not. I could write a competing closed
> > commercial program with the same plug-in API. Surely that
> > cannot mean that automatically my scripts become property of
> > the GIMP dev-community?
>
> Well, derivative works get a new, independent copyright,
> usable subject to the approval of the original copyright
> holder.
>
> If you distribute software linked to GPL libraries, or
> including GPL headers, you have made a derivative work of
> that software. In cases such as separate implementations of
> published APIs, which work a program would be derivative of
> would depend on how it was linked. If you have specific
> questions about non-hypothetical cases, let me know.
--
branko collin
col...@xs4all.nl