Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!news-hog.berkeley.edu!ucberkeley!news.maxwell.syr.edu!newspeer.radix.net!uunet!ash.uu.net!world!buzzard
From: buzzard@world.std.com (Sean T Barrett)
Subject: Re: Glk and Glulx
Message-ID: <GKwpF6.9r6@world.std.com>
Date: Mon, 8 Oct 2001 21:37:54 GMT
References: <PONv7.76$9d.26310@newshog.newsread.com> <9psg4h$ajf$1@news.panix.com> <9psj59$1c4ub$1@hades.csu.net> <9pslud$k9d$1@news.fsf.net>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 46
Xref: news.duke.edu rec.arts.int-fiction:93321

In article <9pslud$k9d$1@news.fsf.net>, Adam Thornton <adam@fsf.net> wrote:
>I think JPEG and PNG are sufficiently well-defined that it isn't a
>problem for them.

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

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

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

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

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

SeanB
