Is it Glk obsolete?
Carlos
Glk specifications are dated on 2000.
For a long time now (more than one year), I've been working upgrading a
glulx targeted author system for the spanish if scene. Well, I've found
that users of that system complaint allways (Glk related) about the same:
- No control of the screen
- Bad sound formats
About the first point I agree 100% with Glk specificaction, so I try to
'teach' users about the benefits of the Glk point of view. About the
second one I agree with complaintners.
Also for a long time (since Inform translation was made around 2001)
I've been hearing about Zarf beeing against supporting Ogg (just
murmurs). As most people on that scene don't read the r*if, things look
very obscure from that side, so I decided to investigate: Well, last
saturday I made a search of 'ogg' on raif archive at Google Groups. And
this is an extract of what I saw:
David Kinder, 2001:
"Since we've got AIFF we might as well keep it, for the disadvantages
you list (and since we've already got files out there using AIFF).
But yes, a compressed audio format is a very good idea, preferrably
one with the minimum of license hassles (i.e. OggVorbis)".
Andrew Plotkin, 2001:
"First, on formats: I like PNG. I like JPEG. I like Ogg. MP3 is iffy,
and Ogg seems to hold the niche perfectly well, so Ogg it is. I don't
like GIF -- yes, I know the patent's expired, but there's nothing
wrong with PNG. And "animated GIF" was more or less a mistake to begin
with. "
David Kinder, en Mayo de 2004, escribió:
"To some extent (I wrote Windows Glk, BTW). I'd prefer to see the Glk
specification get updated, rather than bits getting added at random."
and he also said:
"
> What do you mean by "updated"? To me, adding bits and pieces is* a>
kind of update. Could you elaborate on how such an update would look?
All I meant was that I'd like to see any update done through Andrew, or,
if he doesn't want to, some sort of discussion, rather than everyone
just tack on what they fancied to their favourite Glk lib.
"
Well, we are now in 2005, almost in 2006, and you've been talking about
ogg vorbis at r*if for more than 4 years, but nothing has moved.
David does not implement OggVorbis support because it is not in the
specifications (that sounds common sense), specifications are not
changed even when Zarf is not against that format, he says that he likes
Ogg!!. On the other hand gtkglk by Evin Robertson includes Ogg support
(that maybe is not common sense, but it is moving forward).
All these sound crazy, and I'm beginning to think that it is a problem
of bureaucracy, instead of a technical problem.
Anyway, I tried to think about technical problems, and I didn't find any
problem with OGG that AIFF format do not have already, except the cpu
required to decode Ogg.. and also that is not a problem for Glk, as you
can allways implement glk_schannel_start_ext() just doing nothing if the
resource is a ogg file, and it will still be completely Glk compliant.
I hope I have not been so rude, I'm not blaming anyone, I'm just saying
you've been talking about that for some years and (maybe) it is time to
start moving. Finally, I have to say that I like Glk so much, as much as
I would only ask for just one change: Ogg support (well, actually I'm
passing through requirements of at least 10 authors).
Carlos [Uto at the ifmud].
Paolo Lucchesi
Carlos
> in the Glk.
Yes, you're right.
> But I fully agree. Blorb specs should be updated to include OggVorbis
> support.
It seems that people more or less agree about that. Yesterday on ifmud I
got some opinions from several people, some agree, and other, that maybe
would be glad to write down their own opinions here, disagreed or
understand this delay. As a summary, here they are (sorry, I cannot
remember who said what so I won't write down the names/nicks):
1) I agree but it is Zarf who has to do that, and he is busy/lazy/doing
some other job/not paid for it.
2) It is better to put all the changes in one Glk specifications version
instead of having several versions with minor changes.
3) Authors may then force the game to need Ogg support and so games may
not work on small platforms.
Well, I know that Zarf has to do that, as Glk is (C) Zarf. But I'm
pretty sure that Zarf is probably too busy so... are we going to wait
for more years?. Waiting would make sense if last version was from
2003/2004, but last Glk specifications are dated on 2000. Let's do the
work of putting changes in Glk and when we have finished let's gave them
to Zarf, so he can aproove them and make them the new version of Glk, or
reject them and then we can solve problems. I mean, don't charge all the
load over Zarf's shoulders, let's help him. Is there a suggestion list?
Is there a CVSTrac, bugtracker or similar?
About not creating a version every 3 months, I agree. But there have
been 5 years since last version, while since 1997 to 2000 there where
more than 6 versions.
About what authors can do... well, I think that authors may be teached,
and he can learn why you don't have to do some kind of things, but no
one can avoid an stupid guy from doing stupid things, it doesn't matter
if there is ogg support or not. I mean, if the guy bases a puzzle or
just part of the game on sound or images then he/she doesn't understand
how glulx and glk works. But if he is stupid enough to do that he will
do that puzzle using AIFF instead of Ogg, and that will be the same
problem, but with additional Kilobytes.
Also, as I told before, you can do the implementation you want of the
glk comman to play a file, cheapglk does it by just doing nothing, and
I'm pretty sure cheapglk is glk compliant, as it is made by Zarf.
> In the course of Beyond developement we've considered the idea of adding
> a "soundtrack" to the game, but one of the problems we've faced was the
> unsatisfying compromise between audio quality and blorb file size.
Yes, we can read that complaint now and then (at least once a month) on
CAAD forums (Spanish IF forums).
Andrew Plotkin
bad, since I'm in the middle of moving to Boston and my computer is in
a box. I will have a longer post tomorrow night, I hope.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.
Carlos Sanchez
> Let me quickly note that I am reading this thread, but the timing is
> bad, since I'm in the middle of moving to Boston and my computer is in
> a box. I will have a longer post tomorrow night, I hope.
>
> --Z
Ok, thank you for your attention. And please don't hesitate to ask for
help if the problem is that your busy, at least I will hear to help you.
Carlos Sanchez
Aahem.. fast writing ... if *you're* busy ... I will *be here* to help
you O:-)
Michael Coyne
> Let me quickly note that I am reading this thread, but the timing is
> bad, since I'm in the middle of moving to Boston and my computer is in
> a box. I will have a longer post tomorrow night, I hope.
Wow.
I think that's the first Usenet post I've ever read made from inside a box.
Or are you using a different computer?
--
Michael Coyne
http://turthalion.blogspot.com
Andrew Plotkin
Yah. Well, I'll give you the context up front:
When I did the initial Glk libraries, I was very conscious that I had
to do a Mac library, a Curses (Unix terminal) library, and a Unix X
library -- *and* working demo code that was tested on all of those. (I
figured Windows would show up rapidly. Which it did, thank you David
Kinder.)
So I kept updating that stuff -- with simple extensions, like the
hyperlink stuff -- up until 2000. However, around 2001 I bought a new
Mac. And it was OSX time. And I realized that I honestly never wanted
to touch OS9 code ever again. I mean, ew.
Now, I don't think OS9 support is important today. (I would have been
willing to freeze it in 2001, even.) However, I have never had time to
start learning OSX (Cocoa) programming. And Carbon tech is, well, it's
OS9 code with better headers. See "ew" above.
(If you don't know what Cocoa and Carbon are, don't worry about it.
Macs are weird. Cocoa is "ew" too, but in a different way.)
Every once in a while I think I remember someone writing a Cocoa Glk
library. But I can't find it.
There have been times in the past four years that I could have learned
Cocoa and written a library. But I did other stuff. And now, I'm
working at a startup company. (Not IF-related, sorry.) So you caught
me at the worst possible time, heh heh sigh. If my startup fails, I'll
probably learn Cocoa and send a resume to Apple, but that's not how
I'm hoping it goes...
(Yes, the X windows library is pretty much "ew" as well, but I'll
stick my fingers back in if I have to.)
So what I'm worried about is, obviously, that I update the spec (which
I certainly have time to do) and then David Kinder immediately updates
Windows Glk, and then there's a long pause. And the next Glulx game
that comes out is Windows-only.
Call me a bigot, but I'm not going to let that happen.
So, it's a bureaucracy problem, yes. But a technically-based one. If
it were just a matter of writing spec, I'd do it.
(Yes, adding Ogg is a code problem. I ran into this with the *first*
Glk sound release: I said "AIFF! Do it!" and I wrote code to toss the
resource into the OS's sound-playing mechanism. The Mac toolkit on the
Mac, some damn AIFF library on Unix, etc. Result: every implementation
supported a *different subset* of AIFF. To get sound to actually come
out the same everywhere, you had to use a 13-bit-per-pixel AIFF with
nose-tweak compression, or something like that. GIFs were just as bad.
I'm not going through that again. Ideally, the Next Version of Glk
will come with recommended AIFF/OGG/GIF/PNG library code, and all the
libraries will use that code. And that's a bunch of work.)
To deal with various theories:
> 1) I agree but it is Zarf who has to do that, and he is
> busy/lazy/doing some other job/not paid for it.
The sticking point is all the code. If someone jumps up and writes a
Cocoa library -- okay, or even a Carbon one that behaves decently on
OSX -- then we're good.
Anyone?
(insects chirp)
Last year (ish) I tossed up a prospective Unicode extension. There's a
Windows implementation, and I actually got CheapGlk to do it
(presuming UTF-8 output, which actually works on OSX). I was hoping
this would inspire someone to get a Mac version in gear. Didn't
happen. Anyone?
(frogs melt, fish whistle)
> 2) It is better to put all the changes in one Glk specifications
> version instead of having several versions with minor changes.
It is better all to do it at once, but I don't rule out smaller steps.
First step is the tough one. Heck, make the first step Unicode --
we're much closer to having it ready.
> 3) Authors may then force the game to need Ogg support and so games
> may not work on small platforms.
Not a problem, as far as I'm concerned. No games have soundtracks now.
If Ogg is in the spec, then on tiny hardware (and cheapglk), games
would continue to have no soundtracks. No loss. Same goes for Unicode.
There are other Glk changes which would cause more compatibility
issues, but I'd leave those for later.
Paolo Lucchesi
Tor
> Last year (ish) I tossed up a prospective Unicode extension. There's a
> Windows implementation, and I actually got CheapGlk to do it
> (presuming UTF-8 output, which actually works on OSX). I was hoping
> this would inspire someone to get a Mac version in gear. Didn't
> happen. Anyone?
>
> (frogs melt, fish whistle)
Cugel is a Cocoa-based Glk library/application.
Andrew Hunter wrote CocoaGlk which is an even
more Cocoa-based Glk library.
The Unicode extension docs have vanished from the web;
even archive.org doesn't have them. If you still have
them lying around, could you repost them somewhere?
Could you maybe add a section to the stylehints about
the fact that setting the background color of style_Normal actually
means to change the background color of the entire window.
At least, that's what all implementations do, and what all the
games that use stylehints assume.
Tor
Carlos
> I certainly have time to do) and then David Kinder immediately updates
> Windows Glk, and then there's a long pause. And the next Glulx game
> that comes out is Windows-only.
>
> Call me a bigot, but I'm not going to let that happen.
Ummm.. that really makes sense, I couldn't think about it because Mac is
absolutely not spreaded over here, so I never think about Mac O:-).
So I think I cannot help with that, though I will ask at CAAD forums
about it (but I don't think that success). Anyway it seems there is more
movement around Cocoa than expected.
>>3) Authors may then force the game to need Ogg support and so games
>>may not work on small platforms.
>
>
> Not a problem, as far as I'm concerned. No games have soundtracks now.
Well... no *english* games have soundtracks now. There are one spanish
game with soundtrack and even a narrator voice at the begining (32 Mb
blb file, AIFF used). Also there are another spanish adventure using mod
as soundtrack and some SFX. I am myself making a demo of my authoring
system that includes soundtrack (I decided to use MOD not because of
quality, but because of space). And Paolo says Beyond has no soundtrack
because of the file formats. Well, actually there are games with
soundtracks and other games do not have a soundtrack because author
missed something like Ogg.
> If Ogg is in the spec, then on tiny hardware (and cheapglk), games
> would continue to have no soundtracks. No loss. Same goes for Unicode.
cheapglk executes glk_schannel_start_ext by doing nothing (or something
like that). Won't it be Glk compliant for a library to do the same only
when the resource is an Ogg?. I mean, changing libraries to do that it
is easier than changing libraries to actually implement OggVorbis.
dott.piergiorgio
> That's a good point, and I completely agree with you.
> But updating other glk ports (maybe even leaving placeholders at first)
> shouldn't take too long...
The issue on Linux seems residing in two point: first, the use of the
deprecated BSD-ism timezone struct whose barfs at compile time (cruftly
fixed, but not tested), and, more seriously problems with libpng whose
cause the aborting of the compilation of glulxe at linking state because
of many undefined references (deprecated functions again ?)
I use slackware 9.1 and all libraries involved was not
upgradred/replaced/hacked.
Best regards from Italy,
Dott. Piergiorgio.
Andrew Plotkin
> Andrew Plotkin wrote:
> [snip]
> >
> > So what I'm worried about is, obviously, that I update the spec (which
> > I certainly have time to do) and then David Kinder immediately updates
> > Windows Glk, and then there's a long pause. And the next Glulx game
> > that comes out is Windows-only.
> >
> > Call me a bigot, but I'm not going to let that happen.
>
> That's a good point, and I completely agree with you.
> But updating other glk ports (maybe even leaving placeholders at first)
> shouldn't take too long...
Placeholders are what I was just saying I *don't* want.
Of course, it depends on how crucial the functionality is. For sound
support, I'm okay with slow adoption across different platforms.
However, Unicode is a bigger pill to swallow. If a game uses Unicode
input and output, it probably can't be played without that
functionality. "Placeholder" Unicode support is therefore not good
enough.
(Although there are games that use Unicode in a purely decorative and
optional way. E.g., Mingsheng (Z-code).)
> > The sticking point is all the code. If someone jumps up and writes a
> > Cocoa library -- okay, or even a Carbon one that behaves decently on
> > OSX -- then we're good.
> >
> > Anyone?
>
> Tor Andersson is developing, along with his Gargoyle glk port for
> windows/linux, his Cugel project that, AFAIK, is based on a Cocoa glk
> port (I have no OsX machine to test it).
Okay, that (and Andrew Hunter's work) are what I was remembering.
(Neither of them is on the Archive, and Google couldn't find either of
them. And I haven't taken a close look at Cugel at all.)
The Unicode spec, to answer that question, is at
<http://www.eblong.com/zarf/glk/tmp/>.
It's been at "draft" stage for several months, as I said, because
implementation seemed to be stalled. If that's only because not enough
people knew about it (the discussion was on the Inform mailing list)
then I'm an idiot -- I apologize. Let us begin the forward momentum.
Here, dott.piergiorgio <dott.pierg...@soryufastwebnet.it>
wrote:
>
> The issue on Linux seems residing in two point: first, the use of
> the deprecated BSD-ism timezone struct whose barfs at compile time
> (cruftly fixed, but not tested), and, more seriously problems with
> libpng whose cause the aborting of the compilation of glulxe at
> linking state because of many undefined references (deprecated
> functions again ?)
The timezone thing is trivial: the second argument to gettimeofday
should be NULL. As for libpng, we need to use the current library
version on all platforms.
David Kinder
> The Unicode spec, to answer that question, is at
> <http://www.eblong.com/zarf/glk/tmp/>.
>
> It's been at "draft" stage for several months, as I said, because
> implementation seemed to be stalled. If that's only because not enough
> people knew about it (the discussion was on the Inform mailing list)
> then I'm an idiot -- I apologize. Let us begin the forward momentum.
On this subject, if anyone wants to play around with a Windows Glk
that implements the above, it's at:
http://www.d.kinder.btinternet.co.uk/tmp/glulxe.zip
David
Samwyse
Ye-hah! Now for the long pause....
Eric Forgeot
>out the same everywhere, you had to use a 13-bit-per-pixel AIFF with
>nose-tweak compression, or something like that
wow, we got the secret recipe for the Aiff-in-the-blorb cake...
With some fellow programmers we never managed to get those aiff to work
properly with glulx (while it's ok with mod)
For the two excellent mac os x programs Cugel and Zoom, you can find
links to them on those pages :
http://www.ifwiki.org/index.php/Cugel
http://www.inform-fiction.org/zmachine/macos.html
David Kinder
> wow, we got the secret recipe for the Aiff-in-the-blorb cake...
> With some fellow programmers we never managed to get those aiff to work
> properly with glulx (while it's ok with mod)
If you (or anyone) ever have what you think is a valid AIFF that won't
play under Windows Glk, email it to me and I'll try to figure out why it
doesn't work.
David
Carlos Sanchez
Actually, I tryed a lot of AIFFs some time ago, and I also had some
conversation with you by mail those days (you already solved one bug,
something related to some even byte/chunk or .. err... something, or
mayb you just told me how to avoid it, I cannot rememeber well ).
In fact, after some testing, I realized that capability of winGlulxe to
play AIFF files depends too much on converter, and of the exact type of
AIFF file you want to play. I started using WAV2AIFF, but WInglulxe
played no file generated with that application, while Winamp succeded to
play all of them. Using Goldwave you have better chances, but not every
AIFF format works, I had to test a lot to find working files.
On the other hand some aiff files played on WinGlulxe failed on Zag, so
I dediced to recomend user of the authoring system I'm developing to use
some concrete kind of aiff format (something like "8 bits/mono" or
similar, it's written at some thread on CAAD forums) so sound it's
played on both Windows and Linux(as most spanish linux players use Zag).
So I think that you just have to take WAV2AIFF and try, I didn't told to
you on those days because I didn't want to disturb you more, solving
that bug was enough for me :)