[IF Comp] Why Glulx?

38 views
Skip to first unread message

Kevin Bracey

unread,
Nov 22, 2001, 3:14:25 AM11/22/01
to
Here's an open question to the authors of this year's Glulx entries.

Given that you were coding in Inform, what motivated you to target Glulx
rather than the Z-machine?

a) Dynamic memory restrictions
b) Total memory restrictions
c) 32-bit variables
d) Some other capability that Glulx has over the Z-machine
e) Preferring the glk I/O model to the Z-machine's
f) Better glulx/glk support than V6 support on your platform
g) Wanting to push Glulx support forward
h) Other

I am of course asking this from the point of view of someone using a
platform that has a state-of-the-art Z-machine, but no glulx interpreter :)

Kevin
-----

OKB -- not okblacke

unread,
Nov 22, 2001, 1:00:15 PM11/22/01
to
"Kevin Bracey" wrote:
>Here's an open question to the authors of this year's Glulx entries.
>
>Given that you were coding in Inform, what motivated you to target Glulx
>rather than the Z-machine?
>
> a) Dynamic memory restrictions
> b) Total memory restrictions
> c) 32-bit variables
> d) Some other capability that Glulx has over the Z-machine
> e) Preferring the glk I/O model to the Z-machine's
> f) Better glulx/glk support than V6 support on your platform
> g) Wanting to push Glulx support forward
> h) Other

For "an apple from nowhere": d, e, and g (although d and e in this case
might go together -- I'm not sure if text styling really falls under I/O).

For "Stick it to the man": b, d, e, and g.

--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

Kevin Bracey

unread,
Nov 22, 2001, 4:46:05 PM11/22/01
to
"OKB -- not okblacke" <bren...@aol.comRemove> wrote in message
news:20011122130015...@mb-md.aol.com...

> "Kevin Bracey" wrote:
> >Given that you were coding in Inform, what motivated you to target Glulx
> >rather than the Z-machine?
> >
> > a) Dynamic memory restrictions
> > b) Total memory restrictions
> > c) 32-bit variables
> > d) Some other capability that Glulx has over the Z-machine
> > e) Preferring the glk I/O model to the Z-machine's
> > f) Better glulx/glk support than V6 support on your platform
> > g) Wanting to push Glulx support forward
> > h) Other
>
> For "an apple from nowhere": d, e, and g (although d and e in this
case
> might go together -- I'm not sure if text styling really falls under I/O).
>
> For "Stick it to the man": b, d, e, and g.

You did go a bit overboard on the styling, didn't you? Blimey. It reminds me
a little of the mid-90's when everyone discovered Netscape's <BLINK> tag...

On the memory front, presumably the limit you would have hit would be
Inform's artifical 320K limit on V6 - SITTM is only 360K. I'm knocking up a
compiler patch that will lift Inform's V6/V7 memory limit up to 512K.

Kevin
-----

M. D. Krauss

unread,
Nov 22, 2001, 6:56:25 PM11/22/01
to
On Thu, 22 Nov 2001 21:46:05 -0000
"Kevin Bracey" <ke...@bracey-griffith.freeserve.co.uk> wrote:

> "OKB -- not okblacke" <bren...@aol.comRemove> wrote in message
> news:20011122130015...@mb-md.aol.com...

[snip]

> > For "an apple from nowhere": d, e, and g (although d and e in this
> case
> > might go together -- I'm not sure if text styling really falls under I/O).
> >

> > For "Stick it to the man": b, d, e, and g.
>
> You did go a bit overboard on the styling, didn't you? Blimey. It reminds me
> a little of the mid-90's when everyone discovered Netscape's <BLINK> tag...
>

Reminds me of the 80's when everyone discovered
the ANSI blink code.
-M
(Yes!
We had "style" in email before HTML!
We even had animations!
Can't do THAT with HTML...)

OKB -- not okblacke

unread,
Nov 22, 2001, 6:57:31 PM11/22/01
to
"Kevin Bracey" ke...@bracey-griffith.freeserve.co.uk wrote:
>You did go a bit overboard on the styling, didn't you? Blimey. It reminds me
>a little of the mid-90's when everyone discovered Netscape's <BLINK> tag...

<BLINK>I hope you can read HTML usenet posts!</BLINK> :-) Overboard? I
guess that's a matter of opinion.

>On the memory front, presumably the limit you would have hit would be
>Inform's artifical 320K limit on V6 - SITTM is only 360K. I'm knocking up a
>compiler patch that will lift Inform's V6/V7 memory limit up to 512K.

I wasn't considering V6, since I knew (and still know) nothing about how
to use it. It's probable that SITTM would have fit into Z8 (or possibly even
Z5), but that would have meant no menu window, no text styling, etc. Also, I
wasn't sure when I started how large it was going to be.

ems...@mindspring.com

unread,
Nov 23, 2001, 1:34:44 AM11/23/01
to
"Kevin Bracey" <ke...@bracey-griffith.freeserve.co.uk> wrote in message news:<9ticvu$qd7$1...@news5.svr.pol.co.uk>...

a, g. But the reason I want to push Glulx support is that I want more
people to be able to play the future games I anticipate also releasing
in this format.

ES
> -----

Adam Thornton

unread,
Nov 26, 2001, 10:46:22 AM11/26/01
to
In article <9ticvu$qd7$1...@news5.svr.pol.co.uk>,

Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
>Here's an open question to the authors of this year's Glulx entries.
>
>Given that you were coding in Inform, what motivated you to target Glulx
>rather than the Z-machine?
>
> a) Dynamic memory restrictions

No. SMTUC would have fit comfortably in a .z5.

> b) Total memory restrictions

No. See above.

> c) 32-bit variables

Not helpful.

> d) Some other capability that Glulx has over the Z-machine

Yep. Sound and image support, good multi-window support. Yes, v6 does
this too, but...

> e) Preferring the glk I/O model to the Z-machine's

This is one reason for d).

> f) Better glulx/glk support than V6 support on your platform

And this is the other, since I use Linux preferentially.

> g) Wanting to push Glulx support forward

This, kind of. I see Glulx as more useful in the long term than v6, and
I need a full-featured Linux terp.

> h) Other

Doe had already written a nice library to make using Glulx easier.

Adam

Jaap van der Velde

unread,
Nov 26, 2001, 5:09:00 PM11/26/01
to

I am a bit critical on the use of Glulx and I think Adam's
critique shows why:

On Mon, 26 Nov 2001 15:46:22 +0000 (UTC), ad...@fsf.net (Adam
Thornton) wrote:
> In article <9ticvu$qd7$1...@news5.svr.pol.co.uk>,
> Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
> > a) Dynamic memory restrictions
> No. SMTUC would have fit comfortably in a .z5.
> > b) Total memory restrictions
> No. See above.
> > c) 32-bit variables
> Not helpful.

Sofar, I agree. None of these are truly important issues,
except for maybe a few games, most of which can probably
be helped with bigger game-size (fixed with .z8). Which
leaves some Z-machine abuse that may or may not be helped
and I don't think that really explains or necessitates
either the development or use of Glulx. But there's more:



> > d) Some other capability that Glulx has over the Z-machine
> Yep. Sound and image support, good multi-window support. Yes,
> v6 does this too, but...
> > e) Preferring the glk I/O model to the Z-machine's
> This is one reason for d).
> > f) Better glulx/glk support than V6 support on your platform
> And this is the other, since I use Linux preferentially.

So, it all boils down to v6 not being very well supported
and the use of sounds and images as the primary reason to
use either Glulx or .z6? Both multi-media and multi-window
support don't sound very necessary to me right now.

(although I do admit I have some cool ideas on an IC,
an interactive comic, but I sofar think Flash is the way
to go on that one, but let's not get side-tracked)

You see, my problem is that right now the only reasons to
use Glulx aren't very good ones. So I'm curious to any other
reasons the authors have for starting work on it in the
first place. And where do they propose to take it in the
near and foreseeable future?

> > g) Wanting to push Glulx support forward

Which is the only valid reason left, then. Although I still
think Glulx would eventually evolve into something used for
IF that definitely is -not- a text adventure, but a multi-
media experience. Especially since it does not appear to
substantially improve on the parser or other language-
aspects of the z-machine. (or am I wrong?)

> This, kind of. I see Glulx as more useful in the long term
> than v6, and I need a full-featured Linux terp.

Well, I'm not up to date on the IF-cans and -cannots on
Linux, so I'll remain silent there.

But to clearly state my most important question on the
Glulx matter: What does Glulx have to offer the author of
a 'nice and clean' text-adventure with no need for fancy
fonts, images, sounds or any other multi-media experience?
(just as most 'regular' authors of traditional fiction have
no need for these devices)

Grtz,
JAAP.

Andrew Plotkin

unread,
Nov 26, 2001, 5:25:15 PM11/26/01
to
Jaap van der Velde <ve...@bigfoot.com> wrote:

> I am a bit critical on the use of Glulx and I think Adam's
> critique shows why:

> On Mon, 26 Nov 2001 15:46:22 +0000 (UTC), ad...@fsf.net (Adam
> Thornton) wrote:
>> In article <9ticvu$qd7$1...@news5.svr.pol.co.uk>,
>> Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
>> > a) Dynamic memory restrictions
>> No. SMTUC would have fit comfortably in a .z5.
>> > b) Total memory restrictions
>> No. See above.
>> > c) 32-bit variables
>> Not helpful.

> Sofar, I agree. None of these are truly important issues,
> except for maybe a few games, most of which can probably
> be helped with bigger game-size (fixed with .z8).

I would point out that Emily is *not* the first person ever to find
the Z-machine inadequate.

We have a long history of people -- not everybody, but still a fair
number of people -- running into Z-machine limits on global variables,
properties, attributes, and RAM (which must include property data,
array data, and the dictionary). None of those are helped by switching
to Z8.

--Z

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

Magnus Olsson

unread,
Nov 26, 2001, 6:41:11 PM11/26/01
to
In article <3c05b706...@news.student.utwente.nl>,

Jaap van der Velde <ve...@bigfoot.com> wrote:
>Which is the only valid reason left, then. Although I still
>think Glulx would eventually evolve into something used for
>IF that definitely is -not- a text adventure, but a multi-
>media experience. Especially since it does not appear to
>substantially improve on the parser or other language-
>aspects of the z-machine. (or am I wrong?)

I think you're slightly confused about what Glulx really
is, or, rather, that you're talking about the current
combination of Bi-platform Inform compiler/library and
Glk.

Glulx itself is just a virtual machine (glulxe) and its
machine language. It's sufficiently general to be used
for anything you can think of.

>But to clearly state my most important question on the
>Glulx matter: What does Glulx have to offer the author of
>a 'nice and clean' text-adventure with no need for fancy
>fonts, images, sounds or any other multi-media experience?

Basically, if you don't want that "fancy" stuff, you can think of
Glulx as an alternative to the Z-machine that offers more memory,
32-bit arithmetic, a larger number of function parameters and possibly
some other things as well.

So as long as your game isn't too large and your code isn't
too complex, you can just as well compile to Z-code. That will
give you a greater choice of interpreters today; I expect that
will change in the future.

What I expect is going to happen among authors of "nice and
clean" text adventures is that some of them will write so
large or complex games that they can't fit them within the
Z-machine. In such a case, moving to Glulx is *really simple*.

If you *are* going to use even slightly fancy stuff, such
as menues that are placed at the bottom of the screen rather
than at the top, or different sizes of text, or both bold
and italic text in the same game, then you can use Glulx
but not the Z-machine.

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

Kevin Bracey

unread,
Nov 27, 2001, 6:52:22 AM11/27/01
to
In message <9tujun$94l$2...@news.lth.se>
m...@df.lth.se (Magnus Olsson) wrote:

> If you *are* going to use even slightly fancy stuff, such
> as menues that are placed at the bottom of the screen rather
> than at the top, or different sizes of text, or both bold
> and italic text in the same game, then you can use Glulx
> but not the Z-machine.

Oh, complete rubbish. Why do people keep saying things like that? You can do
any of that in V6, except change the font size. And I'm not terribly
convinced of the aesthetic benefits of changing font size. How many books do
you see that don't stick to a single typeface?

The Z-machine even goes beyond Glulx/glk in a number of areas:

1) Overlaying text on pictures
2) More flexible textual layout - I can't see any way of replicating
something as simple as "box" in glk
3) Support for more than just Latin-1
4) The ability to flow text around irregularly shaped images
5) Native menu support

Just because your Z-code interpreter's ropey isn't any reason to start making
claims like that about the Z-machine as a whole.

In fact, as far as display is concerned, the only thing I can think of that
glk can do that V6 can't is changing font size. Admittedly a lot of things
are easier with glk than with raw V6, but then that's what V6Lib's for.
Getting non-primary text colours is tricky, but possible.

Sorry, I'll attempt to calm down now. I've just got this chip on my shoulder
from creating Zip 2000 with state-of-the-art V6 support three years ago, and
since then no-one else on any other platform has managed to get V6 support
functioning well enough for anyone to actually use it. Even Moments Out Of
Time is woefully crude (in the UI department) compared to what Infocom did
with V6.

It doesn't help that the standard Inform library doesn't handle V6 properly,
and that the compiler restricts V6 to 320K. However, I'm fixing all these
problems and submitting them to Roger Firth's patch page.

--
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc Tel: +44 (0) 1223 518566
645 Newmarket Road Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom WWW: http://www.pace.co.uk/

Magnus Olsson

unread,
Nov 27, 2001, 7:30:33 AM11/27/01
to
In article <31d0f6df4...@kbracey.cam.pace.co.uk>,

Kevin Bracey <kevin....@pace.co.uk> wrote:
>In message <9tujun$94l$2...@news.lth.se>
> m...@df.lth.se (Magnus Olsson) wrote:
>
>> If you *are* going to use even slightly fancy stuff, such
>> as menues that are placed at the bottom of the screen rather
>> than at the top, or different sizes of text, or both bold
>> and italic text in the same game, then you can use Glulx
>> but not the Z-machine.
>
>Oh, complete rubbish. Why do people keep saying things like that?

In this case, because I simply forgot z6. I must also say that I'm not
very sure of what you can and can't do in z6, except that its concept
of a window is different from that of Glk (which is used by Glulx
Inform).

>You can do
>any of that in V6, except change the font size. And I'm not terribly
>convinced of the aesthetic benefits of changing font size. How many books do
>you see that don't stick to a single typeface?

That's a false analogy - books aren't designed to be read on-screen.
Anyway, the only use I can see for a larger font size in "pure" text
IF (not even ASCII graphics allowed :-) ) is for headlines and stuff
like that.

>The Z-machine even goes beyond Glulx/glk in a number of areas:
>
> 1) Overlaying text on pictures
> 2) More flexible textual layout - I can't see any way of replicating
> something as simple as "box" in glk
> 3) Support for more than just Latin-1
> 4) The ability to flow text around irregularly shaped images
> 5) Native menu support

...of which only 3) is relevant for what we were discussing, viz.
"pure" text IF.

>Sorry, I'll attempt to calm down now.

Yes, you seem a bit excited :-).

>I've just got this chip on my shoulder
>from creating Zip 2000 with state-of-the-art V6 support three years ago, and
>since then no-one else on any other platform has managed to get V6 support
>functioning well enough for anyone to actually use it.

This is indeed sad, but...

...it's easy to say "look at all these wonderful things you can do
with V6". Has anybody actually expressed regret at not being
able to do these things in other systems? I'm not being sarcastic,
I'm just wondering if we really need to invest a lot of time in getting
V6 to work properly when nobody seems to want to use it. Yes, yes,
I know; let me reformulate: would many peopel want to use V6 if there
were more interpreters available? Why, or why not?

Jason C. Penney

unread,
Nov 27, 2001, 7:43:56 AM11/27/01
to
Magnus Olsson <m...@df.lth.se> wrote:
> In article <31d0f6df4...@kbracey.cam.pace.co.uk>,
> Kevin Bracey <kevin....@pace.co.uk> wrote:

>>The Z-machine even goes beyond Glulx/glk in a number of areas:
>>
>> 1) Overlaying text on pictures
>> 2) More flexible textual layout - I can't see any way of replicating
>> something as simple as "box" in glk
>> 3) Support for more than just Latin-1
>> 4) The ability to flow text around irregularly shaped images
>> 5) Native menu support

> ...of which only 3) is relevant for what we were discussing, viz.
> "pure" text IF.

While I guess it's outside the boundaries of "pure" IF, V6 "box"
support was one of the most requested features in early V6Lib releases.
Would using interesting text layout (like flowing text around images
that weren't there) be outside "pure" IF?

>>I've just got this chip on my shoulder
>>from creating Zip 2000 with state-of-the-art V6 support three years ago, and
>>since then no-one else on any other platform has managed to get V6 support
>>functioning well enough for anyone to actually use it.

> ...it's easy to say "look at all these wonderful things you can do


> with V6". Has anybody actually expressed regret at not being
> able to do these things in other systems? I'm not being sarcastic,
> I'm just wondering if we really need to invest a lot of time in getting
> V6 to work properly when nobody seems to want to use it. Yes, yes,
> I know; let me reformulate: would many peopel want to use V6 if there
> were more interpreters available? Why, or why not?

I would say more people would, yes, since I have over the past few
years worked with about 10 different people on V6 games. Some of them
got disgusted with the lack of support and went to Glk, or standard
z-machine, and some of them just gave up the whole idea. To me the
latter is upsetting because those works may never be seen now.

Jay

--
Jason C Penney (jpenney [AT] jczorkmid.net) Xarton Dragon -=<UDIC>=-
<http://www.jczorkmid.net>
"Time and tide melts the snow man." --The Doctor

Magnus Olsson

unread,
Nov 27, 2001, 7:51:43 AM11/27/01
to
In article <gULM7.113$zX1.3...@typhoon.ne.mediaone.net>,

Jason C. Penney <jpe...@jczorkmid.SPAMOFF.net> wrote:
>Magnus Olsson <m...@df.lth.se> wrote:
>> In article <31d0f6df4...@kbracey.cam.pace.co.uk>,
>> Kevin Bracey <kevin....@pace.co.uk> wrote:
>
>>>The Z-machine even goes beyond Glulx/glk in a number of areas:
>>>
>>> 1) Overlaying text on pictures
>>> 2) More flexible textual layout - I can't see any way of replicating
>>> something as simple as "box" in glk
>>> 3) Support for more than just Latin-1
>>> 4) The ability to flow text around irregularly shaped images
>>> 5) Native menu support
>
>> ...of which only 3) is relevant for what we were discussing, viz.
>> "pure" text IF.
>
>While I guess it's outside the boundaries of "pure" IF, V6 "box"
>support was one of the most requested features in early V6Lib releases.
>Would using interesting text layout (like flowing text around images
>that weren't there) be outside "pure" IF?

The distinction is more than a little bit silly, but I was writing
within the context of the original question:
[paraphrased from memory] "What will Glulx offer me over Z-code
if I'm not interested in doing any 'fancy' stuff".

Personalyl, I think that even "pure" text adventures can use things
like fonts, colours, and, indeed, boxes to great advantage.

>>would many peopel want to use V6 if there
>> were more interpreters available? Why, or why not?
>
>I would say more people would, yes, since I have over the past few
>years worked with about 10 different people on V6 games. Some of them
>got disgusted with the lack of support and went to Glk, or standard
>z-machine, and some of them just gave up the whole idea.

Oh. I didn't know that.

To continue to play Devil's advocate (or, perhaps, Glk's advocate),
were these projects started before other graphics-capable systems
were available?

Jason C. Penney

unread,
Nov 27, 2001, 8:18:17 AM11/27/01
to
Magnus Olsson <m...@df.lth.se> wrote:
> In article <gULM7.113$zX1.3...@typhoon.ne.mediaone.net>,
> Jason C. Penney <jpe...@jczorkmid.SPAMOFF.net> wrote:

>>>would many peopel want to use V6 if there
>>> were more interpreters available? Why, or why not?
>>
>>I would say more people would, yes, since I have over the past few
>>years worked with about 10 different people on V6 games. Some of them
>>got disgusted with the lack of support and went to Glk, or standard
>>z-machine, and some of them just gave up the whole idea.

> Oh. I didn't know that.

> To continue to play Devil's advocate (or, perhaps, Glk's advocate),
> were these projects started before other graphics-capable systems
> were available?

Well, if I'm remembering my history correctly:

Dec 97 - Glk proposal was released.
Jan 98 - first public V6Lib and manual were released
Apr 98 - HTML TADS was released.

HTML TADS was the most impressive since it was announced, and released
with a fully capable terp right away. Glk and V6 were both uncertain.
Most of the interest in V6Lib came between mid 1998-1999. (Not to say
it's died out completely... Jon "My Angel" Ingold's NovelLib release
has full V6Lib support).

Kevin Bracey

unread,
Nov 27, 2001, 10:23:24 AM11/27/01
to
In message <gULM7.113$zX1.3...@typhoon.ne.mediaone.net>

"Jason C. Penney" <jpe...@jczorkmid.SPAMOFF.net> wrote:

> Magnus Olsson <m...@df.lth.se> wrote:
> > In article <31d0f6df4...@kbracey.cam.pace.co.uk>,
> > Kevin Bracey <kevin....@pace.co.uk> wrote:
>
> >>The Z-machine even goes beyond Glulx/glk in a number of areas:
> >>
> >> 1) Overlaying text on pictures
> >> 2) More flexible textual layout - I can't see any way of replicating
> >> something as simple as "box" in glk
> >> 3) Support for more than just Latin-1
> >> 4) The ability to flow text around irregularly shaped images
> >> 5) Native menu support
>
> > ...of which only 3) is relevant for what we were discussing, viz.
> > "pure" text IF.

If you're talking about pure text IF, then none of glk's fancy features are
required at all - just compile for V5/V8; it's only memory limits that are an
issue then. You explicitly said that the Z-machine being unable to do any
sort of fancy effects, which is patently false.

>
> While I guess it's outside the boundaries of "pure" IF, V6 "box"
> support was one of the most requested features in early V6Lib releases.
> Would using interesting text layout (like flowing text around images
> that weren't there) be outside "pure" IF?

Does it do box now? I've just coded it up myself for an Inform patch this
morning. I've been following a vanila Z-code model for these patches, rather
than the class-based architecture of V6Lib.

> > ...it's easy to say "look at all these wonderful things you can do
> > with V6". Has anybody actually expressed regret at not being
> > able to do these things in other systems? I'm not being sarcastic,
> > I'm just wondering if we really need to invest a lot of time in getting
> > V6 to work properly when nobody seems to want to use it. Yes, yes,
> > I know; let me reformulate: would many peopel want to use V6 if there
> > were more interpreters available? Why, or why not?

That's the point, isn't it - people are obviously wanting to do these things
and they're turning to Glulx to do them. I'm just standing up for the older
existing standard, and saying that it shouldn't be dismissed so readily,
especially by people making false claims about missing features.

>
> I would say more people would, yes, since I have over the past few
> years worked with about 10 different people on V6 games. Some of them
> got disgusted with the lack of support and went to Glk, or standard
> z-machine, and some of them just gave up the whole idea. To me the
> latter is upsetting because those works may never be seen now.

So what should I be concentrating my effort on? What's missing? How can we
make it easier? The two main problems are lack of decent V6 interpreters on
some platforms, and maybe insufficient abstraction. What are the best V6
interpreters on each platform, and how far do they go? I'll start the list:


Platform Terp Standard Versions Blorb PNG JPEG AIFF MOD SONG
----------------------------------------------------------------------------
RISC OS Zip 2000 1.0, no omissions 12345678 Yes Yes Yes Yes Yes Yes
http://www.bracey-griffith.freeserve.co.uk/Zip2000/

Please add your top terps...

As for abstraction, what about implementing the glk API in V6? Would that
help? I'm pretty certain that that's quite possible, with near total
functionality.

Magnus Olsson

unread,
Nov 27, 2001, 11:04:27 AM11/27/01
to
In article <7c220ae04...@kbracey.cam.pace.co.uk>,

Kevin Bracey <kevin....@pace.co.uk> wrote:
>In message <gULM7.113$zX1.3...@typhoon.ne.mediaone.net>
> "Jason C. Penney" <jpe...@jczorkmid.SPAMOFF.net> wrote:
>
>> Magnus Olsson <m...@df.lth.se> wrote:
>> >>The Z-machine even goes beyond Glulx/glk in a number of areas:
>> >>
>> >> 1) Overlaying text on pictures
>> >> 2) More flexible textual layout - I can't see any way of replicating
>> >> something as simple as "box" in glk
>> >> 3) Support for more than just Latin-1
>> >> 4) The ability to flow text around irregularly shaped images
>> >> 5) Native menu support
>> > ...of which only 3) is relevant for what we were discussing, viz.
>> > "pure" text IF.
>
>If you're talking about pure text IF, then none of glk's fancy features are
>required at all - just compile for V5/V8; it's only memory limits that are an
>issue then.

This is getting more than a little bit silly, since it's just a matter
of defining "pure text IF" and "fancy features". But let me try,
since I'm feeling a bit pedantic:

If by "pure text IF" we mean a game that uses only text in its output,
but may use different fonts, font sizes, italic/bold, and colours, then
only 3) above is relevant, and Glk has *a few* more features than the
v5/v8 Z machine.

But I'm not sure why anybody would be such a purist as to refuse to
use any "fancy" features - even a "pure" text game could benefit from
the "fancy" features.

And Glulx offers more than more memory: it also offers 32-bit
arithmetic and relaxes most of those irritating limitations of the
Z-machine, all of which could be of interest to all IF authors.

>You explicitly said that the Z-machine being unable to do any
>sort of fancy effects, which is patently false.

As I've already explained, I was talking about V5/V8 and simply forgot
V6, which is of course wrong.

Mea culpa. Bad, *bad* Magnus. Now, can we go on, please?

Kevin Bracey

unread,
Nov 27, 2001, 12:34:48 PM11/27/01
to
In message <9u0dib$lrp$1...@news.lth.se>
m...@df.lth.se (Magnus Olsson) wrote:

> But I'm not sure why anybody would be such a purist as to refuse to
> use any "fancy" features - even a "pure" text game could benefit from
> the "fancy" features.

Maybe, but don't forget the portability expense. Is it really so important
to have your background a particular shade of blue with such and such a point
size of chapter headings that you rule out all but three platforms? I'm sure
the number of platforms Glulx works on will gradually increase, but I doubt
it will ever reach the number of the Z-machine. And no-one's made a Glulx
interpreter for my platform yet :(

>
> And Glulx offers more than more memory: it also offers 32-bit
> arithmetic and relaxes most of those irritating limitations of the
> Z-machine, all of which could be of interest to all IF authors.

Indeed, but of less interest to IF _players_. In a sense what I'm trying to
do here is ask people not to forget the portability of the Z-machine, and
dispel oft-repeated misconceptions about its capabilities.

Just as everyone here jumps on people who say "why not use Java", I'm jumping
on people who say "why not use Glulx". Glulx is lovely, and provides a number
of things the Z-machine cannot, but ask yourself - do you really need it?

Magnus Olsson

unread,
Nov 27, 2001, 1:59:57 PM11/27/01
to
In article <092a16e04...@kbracey.cam.pace.co.uk>,

Kevin Bracey <kevin....@pace.co.uk> wrote:
>In message <9u0dib$lrp$1...@news.lth.se>
> m...@df.lth.se (Magnus Olsson) wrote:
>
>> But I'm not sure why anybody would be such a purist as to refuse to
>> use any "fancy" features - even a "pure" text game could benefit from
>> the "fancy" features.
>
>Maybe, but don't forget the portability expense. Is it really so important
>to have your background a particular shade of blue with such and such a point
>size of chapter headings that you rule out all but three platforms? I'm sure
>the number of platforms Glulx works on will gradually increase, but I doubt
>it will ever reach the number of the Z-machine. And no-one's made a Glulx
>interpreter for my platform yet :(

On the other hand, how many platforms have full implementations of
the V6 Z-machine? One, if I understand things correctly.

>> And Glulx offers more than more memory: it also offers 32-bit
>> arithmetic and relaxes most of those irritating limitations of the
>> Z-machine, all of which could be of interest to all IF authors.
>
>Indeed, but of less interest to IF _players_.

Well, yes, if the lack of those features just means a minor inconvenience
for the author. But if the inconvenience is such that the game doesn't
get written...

>Just as everyone here jumps on people who say "why not use Java", I'm jumping
>on people who say "why not use Glulx". Glulx is lovely, and provides a number
>of things the Z-machine cannot, but ask yourself - do you really need it?

My agenda is definitely not to persuade people to choose Glulx
over Z-code, but to dispel certain misconceptions about it, just as
ou are combatting misconceptions about Z6.

Matthew Russotto

unread,
Nov 27, 2001, 2:17:32 PM11/27/01
to
In article <9u0nrd$oih$1...@news.lth.se>, Magnus Olsson <m...@df.lth.se> wrote:
>In article <092a16e04...@kbracey.cam.pace.co.uk>,
>Kevin Bracey <kevin....@pace.co.uk> wrote:
>>In message <9u0dib$lrp$1...@news.lth.se>
>> m...@df.lth.se (Magnus Olsson) wrote:
>>
>>> But I'm not sure why anybody would be such a purist as to refuse to
>>> use any "fancy" features - even a "pure" text game could benefit from
>>> the "fancy" features.
>>
>>Maybe, but don't forget the portability expense. Is it really so important
>>to have your background a particular shade of blue with such and such a point
>>size of chapter headings that you rule out all but three platforms? I'm sure
>>the number of platforms Glulx works on will gradually increase, but I doubt
>>it will ever reach the number of the Z-machine. And no-one's made a Glulx
>>interpreter for my platform yet :(
>
>On the other hand, how many platforms have full implementations of
>the V6 Z-machine? One, if I understand things correctly.

Five. Of course, you'll have to encode your files in Infocom format
to use the other four. (Apple IIgs, Mac, Amiga, PC)

Though I admit I'm starting to get motivated to put some Blorb support
into the V6 Zip Infinity and release it on an experimental basis.
Just starting, though.

--
Matthew T. Russotto russ...@pond.com
=====
Get Caught Reading, Go To Jail!
A message from the Association of American Publishers
Free Dmitry Sklyarov! DMCA delenda est!
http://www.freedmitry.org

Kent Tessman

unread,
Nov 27, 2001, 3:26:35 PM11/27/01
to
Aug 97 - Hugo v2.4 released

"Jason C. Penney" <jpe...@jczorkmid.SPAMOFF.net> wrote:

Jason C. Penney

unread,
Nov 27, 2001, 3:57:21 PM11/27/01
to
Kent Tessman <ke...@remove-to-reply.generalcoffee.com> wrote:
> Aug 97 - Hugo v2.4 released

I'm a horrible person. I always say I won't forget Hugo next
time... and I almost always do. Hugo, like TADS was anounced and
released with fully capable terps right away.

sigh...
Jay

--

Andrew Plotkin

unread,
Nov 27, 2001, 4:03:29 PM11/27/01
to
Kevin Bracey <kevin....@pace.co.uk> wrote:
> And no-one's made a Glulx interpreter for my platform yet :(

The no-frills library will work. The curses library should work,
unless your platform lacks a curses library, which I don't think is
true.

If you want to play a multimedia game and not miss out on the graphics
and sound, that will take more work. I can't help you with it. I only
have MacOS and Linux around here.

> Just as everyone here jumps on people who say "why not use Java",
> I'm jumping on people who say "why not use Glulx". Glulx is lovely,
> and provides a number of things the Z-machine cannot, but ask
> yourself - do you really need it?

I have always said that if the capabilities of the V8 Z-machine are
good enough for your game, you have no reason to switch that game to
Glulx.

Kevin Bracey

unread,
Nov 27, 2001, 4:17:04 PM11/27/01
to
"Matthew Russotto" <russ...@wanda.pond.com> wrote in message
news:u07pmco...@corp.supernews.com...

> In article <9u0nrd$oih$1...@news.lth.se>, Magnus Olsson <m...@df.lth.se>
wrote:
> >On the other hand, how many platforms have full implementations of
> >the V6 Z-machine? One, if I understand things correctly.
>
> Five. Of course, you'll have to encode your files in Infocom format
> to use the other four. (Apple IIgs, Mac, Amiga, PC)

I am half-seriously considering writing a Blorb->MG1 converter, tragically.
Stop me before it's too late.

There is a minor gotcha, in that the interpreters for those platforms are of
course commercial products, so you'd have to pay for them. But in the
absence of any freeware alternative...

I was lead to believe by the Z-Spec that Frotz did V6. What's missing?

What about V6 on handhelds? V6, even with graphics, should be possible on
many current handhelds, especially considering that Infocom made do with
320x200 displays. And even without graphics, reasonable fallbacks should be
possible. Anyone looking at this? Or Glulx on handhelds?

> Though I admit I'm starting to get motivated to put some Blorb support
> into the V6 Zip Infinity and release it on an experimental basis.
> Just starting, though.

Feel free to rip as much code as you like out of Zip 2000, or to contact me
with any queries.

Kevin
-----

OKB -- not okblacke

unread,
Nov 27, 2001, 4:27:06 PM11/27/01
to
Kevin Bracey kevin....@pace.co.uk wrote:
>The Z-machine even goes beyond Glulx/glk in a number of areas:
>
> 1) Overlaying text on pictures
> 2) More flexible textual layout - I can't see any way of replicating
> something as simple as "box" in glk
> 3) Support for more than just Latin-1
> 4) The ability to flow text around irregularly shaped images
> 5) Native menu support

This is true, but these have associated sacrifices, most notably loss of
scrollback capability and the requirement that everything be positioned
explicitly. Now, admittedly I dream of the ability to do non-rectangular
windows in Glk, but the advantage of the Glk system is that the windows are
linked to their content.

Kevin Bracey

unread,
Nov 27, 2001, 4:30:09 PM11/27/01
to

"OKB -- not okblacke" <bren...@aol.comRemove> wrote in message
news:20011127162706...@mb-cg.aol.com...

> Kevin Bracey kevin....@pace.co.uk wrote:
> >The Z-machine even goes beyond Glulx/glk in a number of areas:
>
> This is true, but these have associated sacrifices, most notably loss
of
> scrollback capability and the requirement that everything be positioned
> explicitly. Now, admittedly I dream of the ability to do non-rectangular
> windows in Glk, but the advantage of the Glk system is that the windows
are
> linked to their content.

That is very true, and it's something of a performance and memory hit for
Zip 2000 when doing V6, as it suddenly needs a graphical backing store.

I'm sure scrollback of a sort can be done by using pulling text out like you
would when transcripting, and pressing a hot key to switch to scrollback
mode. I'm sure I've seen that done even on non-V6 terps. Not attempted it
myself though.

I'm still pretty convinced that I can implement the glk API in V6. That
might make
authors' lives easier on the manual positioning front.

Kevin
-----

Kevin Bracey

unread,
Nov 27, 2001, 4:36:09 PM11/27/01
to
"Andrew Plotkin" <erky...@eblong.com> wrote in message
news:9u0v31$bje$1...@news.panix.com...

> Kevin Bracey <kevin....@pace.co.uk> wrote:
> > And no-one's made a Glulx interpreter for my platform yet :(
>
> The no-frills library will work. The curses library should work,
> unless your platform lacks a curses library, which I don't think is
> true.

I've just about gotten cheapglk working, apart from the file handling. I've
only found one curses library, and it dates back to 1993, and in turn relies
on all sorts of crusty other libraries. I'll ask around.

>
> If you want to play a multimedia game and not miss out on the graphics
> and sound, that will take more work. I can't help you with it. I only
> have MacOS and Linux around here.

Well, yes. Either of the above would be light-years away from Zip 2000, and
I'm not really relishing the thought of doing all that UI work again from
scratch. Maybe one day when a convincing enough Glulx game comes along... I
did do a bit of work starting off on the VM portions of "Glx 2000", but it
never got very far.

Kevin
-----

Adam Thornton

unread,
Nov 27, 2001, 4:43:18 PM11/27/01
to
In article <9u116r$gli$2...@newsg4.svr.pol.co.uk>,

Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
>"Andrew Plotkin" <erky...@eblong.com> wrote in message
>news:9u0v31$bje$1...@news.panix.com...
>> Kevin Bracey <kevin....@pace.co.uk> wrote:
>> > And no-one's made a Glulx interpreter for my platform yet :(
>> The no-frills library will work. The curses library should work,
>> unless your platform lacks a curses library, which I don't think is
>> true.
>I've just about gotten cheapglk working, apart from the file handling. I've
>only found one curses library, and it dates back to 1993, and in turn relies
>on all sorts of crusty other libraries. I'll ask around.

I'm sorry, but I missed it: which platform?

Adam

David Fillmore

unread,
Nov 27, 2001, 4:47:11 PM11/27/01
to
On 27 Nov 2001 21:27:06 GMT, bren...@aol.comRemove (OKB -- not
okblacke) wrote:

>Kevin Bracey kevin....@pace.co.uk wrote:
>>The Z-machine even goes beyond Glulx/glk in a number of areas:
>>
>> 1) Overlaying text on pictures
>> 2) More flexible textual layout - I can't see any way of replicating
>> something as simple as "box" in glk
>> 3) Support for more than just Latin-1
>> 4) The ability to flow text around irregularly shaped images
>> 5) Native menu support
>
> This is true, but these have associated sacrifices, most notably loss of
>scrollback capability and the requirement that everything be positioned
>explicitly. Now, admittedly I dream of the ability to do non-rectangular
>windows in Glk, but the advantage of the Glk system is that the windows are
>linked to their content.

Assuming you consider that an advantage.

--
Fillmore

Jaap van der Velde

unread,
Nov 27, 2001, 5:49:01 PM11/27/01
to
On 26 Nov 2001 23:41:11 GMT, m...@df.lth.se (Magnus Olsson) wrote:
> > Especially since it does not appear to
> > substantially improve on the parser or other language-
> > aspects of the z-machine. (or am I wrong?)
> I think you're slightly confused about what Glulx really
> is, or, rather, that you're talking about the current
> combination of Bi-platform Inform compiler/library and
> Glk.

Well, not as much confused as in the dark maybe. First of
all, I have to admit I did not know Glulx had such a long
history. Furthermore, the argument that people appear to
think they need it (put up by someone else) as they appear
to be using it, only goes sofar but I can't possible refute
it.

> Glulx itself is just a virtual machine (glulxe) and its
> machine language. It's sufficiently general to be used
> for anything you can think of.

Well, I guess, but the main reason for my asking "Why?"
was my wondering about yet another 'new' system. I think
IF would be really helped by a few authoring systems
kicking the bucket and more people jumping on the right
bandwagon. If Inform/z-machine is essentially dead (as
in not going to change to allow for larger or more complex
games), I think it would be wise to slowly abandon it. But
I'd hate to have to look back in five years and conclude
we should have staid put.

> Basically, if you don't want that "fancy" stuff, you can think of
> Glulx as an alternative to the Z-machine that offers more memory,
> 32-bit arithmetic, a larger number of function parameters and possibly
> some other things as well.

Well, as you can guess, I'd rather think of it as a
definitive replacement instead of an alternative. I think
IF has been 'blessed' with *enough* alternatives. It's time
to eliminate some of the alternatives in my opinion. Have
a single system that says "pick me!" to new authors and
that is truly convincing to the entire community. This
includes offering some sort of friendly IDE in the long
run to authors that don't want to be programmers.

> So as long as your game isn't too large and your code isn't
> too complex, you can just as well compile to Z-code. That will
> give you a greater choice of interpreters today; I expect that
> will change in the future.

Point is: if everything Z-code has to offer is covered by
Glulx as well, what possible reason could any author of
IF have to pick Z? Sure there are more interpreters out
there but is a 5-minute download really going to stop
anyone? And if Glulx takes almost all z games, why not
recompile (nearly) all of them and offer them as Glulxe-
playable games as well. This will convince every reader
without an interpreter to select Glulxe as his prefered
download instead of some Frotz. No offense intended, I
really enjoy WinFrotz. And of course, I would like to
see a Glulxe for my Palm, but that's a whole 'nother
story.

> What I expect is going to happen among authors of "nice and
> clean" text adventures is that some of them will write so
> large or complex games that they can't fit them within the
> Z-machine. In such a case, moving to Glulx is *really simple*.

Bottom line: I'd like to be able to just ignore the forest
of interpreters and stick with one, preferably the most
popular. Both for my PC and my handheld. And I think I
speak for the larger part of the community in saying that.
Nice and clean to me also means 'easy to run', besides just
being a 'regular' text adventure or work of IF.

Grtz,
JAAP.

Gunther Schmidl

unread,
Nov 27, 2001, 6:20:37 PM11/27/01
to
> Point is: if everything Z-code has to offer is covered by
> Glulx as well, what possible reason could any author of
> IF have to pick Z?

Glulx can't do Z6. Furthermore, I don't like the way the Glulx interpreters
look and it's IMHO a pain in the ass to do Glulx windowing code.

So I'm all against abolishing the Z-machine, thank you very much.

-- Gunther


Alan Trewartha

unread,
Nov 27, 2001, 7:29:59 PM11/27/01
to
> And no-one's made a Glulx interpreter for my platform yet :(

> What are the best V6 interpreters on each platform, and how far do they


> go? I'll start the list:
>
> Platform Terp Standard Versions Blorb PNG JPEG AIFF MOD SONG
> ----------------------------------------------------------------------------
> RISC OS Zip 2000 1.0, no omissions 12345678 Yes Yes Yes Yes Yes Yes

GO KEVIN!!

There that's my raif contribution for the next couple of months. we should
have a riscos anthem or something just to rally the troops.

i'm watching you all. very well done i must say.

Alan

Andrew Plotkin

unread,
Nov 27, 2001, 10:58:02 PM11/27/01
to
Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
> [...] and I'm not really relishing the thought of doing all that UI
> work again from scratch.

Now that sounds very similar to a thought I was having around, oh,
1996 or 1997, as I was ripping the UI out of MaxZip for MaxTADS and
rewriting it for, what was it, the third or fourth time. :-)

dgr...@cs.csuabk.edu

unread,
Nov 27, 2001, 11:02:30 PM11/27/01
to
Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:

> I was lead to believe by the Z-Spec that Frotz did V6. What's missing?

Frotz does indeed do V6. Under DOS and Windows, graphical V6 works fine.
Unix Frotz will do nongraphical V6 fine and draw outlines where graphics
should be. Xfrotz handles graphical V6 acceptably, but since it's based
on straight 2.32 Frotz, it's rather dated. Full V6 support in Unix Frotz
is still experimental.


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

Magnus Olsson

unread,
Nov 28, 2001, 3:35:12 AM11/28/01
to
In article <3c04f9f4...@news.student.utwente.nl>,

Jaap van der Velde <ve...@bigfoot.com> wrote:
>Furthermore, the argument that people appear to
>think they need it (put up by someone else) as they appear
>to be using it, only goes sofar but I can't possible refute
>it.

Well, how could it possibly be refuted?

"Why are you using Glulx?"
"Because I think I need it."
"No, you don't think you need it."
"How can you know what I think?"

:-)

>> Glulx itself is just a virtual machine (glulxe) and its
>> machine language. It's sufficiently general to be used
>> for anything you can think of.
>
>Well, I guess, but the main reason for my asking "Why?"
>was my wondering about yet another 'new' system. I think
>IF would be really helped by a few authoring systems
>kicking the bucket and more people jumping on the right
>bandwagon.

I may seem like I'm nitpicking, but I really don't think Glulx,
or even Glulx Inform, should be referred to as a new authoring
system. When people are talking about "Switching from Inform to
Glulx" they make it sound like it's a really big step, which it
isn't.

An analogy: Switching from Inform/Z-code to Inform/Glulx is not like
switching from C++ to Java, it's more like changing UI libraries under
C++.

>If Inform/z-machine is essentially dead (as
>in not going to change to allow for larger or more complex
>games), I think it would be wise to slowly abandon it.

People whose games require features not supported by the Z machine
will *have* to abandon it (unless the plans for a V9 Z machine
are set into motion). I can't really see why people who don't need
such features should abandon it, as long as Graham and the interpreter
writers support it.

I think th edefinition of "dead" for a software system shouldn't be
when it's stopped growing, it should be when it's no longer being
maintained.

>> Basically, if you don't want that "fancy" stuff, you can think of
>> Glulx as an alternative to the Z-machine that offers more memory,
>> 32-bit arithmetic, a larger number of function parameters and possibly
>> some other things as well.
>
>Well, as you can guess, I'd rather think of it as a
>definitive replacement instead of an alternative.

But why would we need to replace the Z-machine for the uses where
it's sufficient? Remember that if we truly *wanted* to replace
the Z-machine with Glulxe everywhere, we'd have to recompile all old
Inform games to Glulx as well. And, as has been pointed out, for
V6 games that's not even possible.

>I think
>IF has been 'blessed' with *enough* alternatives. It's time
>to eliminate some of the alternatives in my opinion.

And just how do you propose to do that?

>Have
>a single system that says "pick me!" to new authors and
>that is truly convincing to the entire community.

Bleargh. I suppose you want just one make of car on sale, and
one brand of toothpaste?

>Point is: if everything Z-code has to offer is covered by
>Glulx as well, what possible reason could any author of
>IF have to pick Z? Sure there are more interpreters out
>there but is a 5-minute download really going to stop
>anyone?

If there simply isn't a Glulxe port to your system, it damn
well is going to stop you.

>And if Glulx takes almost all z games, why not
>recompile (nearly) all of them and offer them as Glulxe-
>playable games as well.

To begin with, you'll need access to the source. Then you need
bi-platform versions of all previous versions of both the compiler and
the library (beccuase there are enough incompatibility that old source
won't work with the current versions).

Kevin Bracey

unread,
Nov 28, 2001, 3:32:04 AM11/28/01
to
"Jaap van der Velde" <ve...@bigfoot.com> wrote in message
news:3c04f9f4...@news.student.utwente.nl...

> On 26 Nov 2001 23:41:11 GMT, m...@df.lth.se (Magnus Olsson) wrote:
>
> Point is: if everything Z-code has to offer is covered by
> Glulx as well, what possible reason could any author of
> IF have to pick Z? Sure there are more interpreters out
> there but is a 5-minute download really going to stop
> anyone?

Something tells me you're a PC/Mac/Linux user. No other platform has a Glulx
interpreter yet, let alone a decent one. Now, if everyone pulled their
finger out and wrote a Glulx interpreter for every platform that currently
has a Z-machine, we'd be laughing. Maybe one day. And then, interestingly,
Glulx would lose one of its advantages for authors - at present there's near
total uniformity in the interpreters that people use; they don't have to
worry too much at the moment about screen size issues etc.

And Glulx cannot do everything the Z-machine can do. There's no way
Infocom's 4 V6 games could be rendered faithfully in Glulx, and Glulx is for
some reason limited to Latin1 support only. Even relatively simple things
like menu systems that use proportional fonts are totally beyond it. Some of
these restrictions will probably be lifted by later versions, others are
fundamental parts of deliberate compromises in its design, albeit taken with
good reason.

> And if Glulx takes almost all z games, why not
> recompile (nearly) all of them and offer them as Glulxe-
> playable games as well. This will convince every reader
> without an interpreter to select Glulxe as his prefered
> download instead of some Frotz. No offense intended, I
> really enjoy WinFrotz. And of course, I would like to
> see a Glulxe for my Palm, but that's a whole 'nother
> story.

I see exactly where you're coming from. But until someone writes a complete
Z-machine in Glulx, that isn't going to happen. Now, the more people that
use Glulx the more pressure there will be for people to write Glulx
interpreters, but I can't help but feel that there aren't enough active
programmers in the community to cover all the platforms that people are
currently using, so users will be left terpless.

So on the one hand you'll have the convenience of only running one terp, but
other people will be left totally unable to play the games. That seems a bit
skewed to me. I am strongly in favour of using the Z-machine if at all
possible.

> Bottom line: I'd like to be able to just ignore the forest
> of interpreters and stick with one, preferably the most
> popular. Both for my PC and my handheld. And I think I
> speak for the larger part of the community in saying that.
> Nice and clean to me also means 'easy to run', besides just
> being a 'regular' text adventure or work of IF.

We have tolerated too much variance in the capabilities of Z-code
interpreters; people have been coding around terp bugs for too long, and
possibly not lobbying the maintainers of the broken ones enough. There is a
very clear standard saying what the interpreters should be doing, so in
theory (hah) there should be no portability problems in the Z-machine. That
there are just reflects how widely ported the Z-machine is. As soon as Glulx
comes anywhere near the number of platforms, it will have just the same
problems.

Kevin
-----

Magnus Olsson

unread,
Nov 28, 2001, 3:43:37 AM11/28/01
to
In article <9u27kd$16q$1...@newsg1.svr.pol.co.uk>,

Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
>"Jaap van der Velde" <ve...@bigfoot.com> wrote in message
>news:3c04f9f4...@news.student.utwente.nl...
>> On 26 Nov 2001 23:41:11 GMT, m...@df.lth.se (Magnus Olsson) wrote:
>>
>> Point is: if everything Z-code has to offer is covered by
>> Glulx as well, what possible reason could any author of
>> IF have to pick Z?

For the record: Jaap wrote that, not I. (Yes, you can count
the number of >'s and reach that conclusion, but still...)

>We have tolerated too much variance in the capabilities of Z-code
>interpreters; people have been coding around terp bugs for too long, and
>possibly not lobbying the maintainers of the broken ones enough.

Also, before the standard document existed, terps were designed by
reverse-engineering Infocom games. It's no wonder different reverse
engineers reached different conclusions, or made mistakes.

>As soon as Glulx
>comes anywhere near the number of platforms, it will have just the same
>problems.

I think the problems will not be with the glulx VM, since (unlike
for the Z-machine) there is a reference implementation (glulxe).
The problems will be with Glk.

Magnus Olsson

unread,
Nov 28, 2001, 3:59:01 AM11/28/01
to
In article <9u27kd$16q$1...@newsg1.svr.pol.co.uk>,
Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
>Something tells me you're a PC/Mac/Linux user. No other platform has a Glulx
>interpreter yet, let alone a decent one.

Shouldn't it be possible to compile glulxe and CheapGlk on most
systems with a standard C compiler? Or at least on Posix compliant
systems?

Of course, the resulting interpreter may not meet your definition
of "decent". :-)

>And Glulx cannot do everything the Z-machine can do. There's no way
>Infocom's 4 V6 games could be rendered faithfully in Glulx, and Glulx is for
>some reason limited to Latin1 support only.

Multiple character sets shouldn't bee too difficult, should it? Zarf?

>Even relatively simple things
>like menu systems that use proportional fonts are totally beyond it.

I'm afraid you've lost me there - care to explain?

>Some of
>these restrictions will probably be lifted by later versions, others are
>fundamental parts of deliberate compromises in its design, albeit taken with
>good reason.

The fundamental difference that I can think of is the inability to
mix graphics and text, like for example putting a graphical border around
the text window or to let text float around an image. And these can
be quite a killer factor if you want, say, a game window that
looks like an illuminated manuscript, with initials and miniatures and
borders, or one that looks like the archaeologist's diary in "Beetmonger".

Kevin Bracey

unread,
Nov 28, 2001, 7:15:43 AM11/28/01
to
In message <9u290l$5sj$4...@news.lth.se>
m...@df.lth.se (Magnus Olsson) wrote:

> Shouldn't it be possible to compile glulxe and CheapGlk on most
> systems with a standard C compiler? Or at least on Posix compliant
> systems?

Yes, I've managed cheapglk, except I haven't sorted out its file handling.
I bet a lot of Glk programs won't like RISC OS' filenaming system though.

>
> Of course, the resulting interpreter may not meet your definition
> of "decent". :-)

Exactly. :)

>
> >Even relatively simple things
> >like menu systems that use proportional fonts are totally beyond it.
>
> I'm afraid you've lost me there - care to explain?

You cannot move the cursor in a text window, so you cannot provide the
capability to do Menus.h / AltMenu.h type functionality unless you use a
character grid window, which limits you to an ugly fixed space font. Now,
that's the same limitation that V5 has, but V6 lifted that restriction. Look
at Zork Zero's hints, for example, or Journey's bottom of screen menus.

Of course, this was a deliberate design decision for Glk, because as soon as
you can position the cursor in a non-character grid window, you need a
graphical backing store.

>
> >Some of
> >these restrictions will probably be lifted by later versions, others are
> >fundamental parts of deliberate compromises in its design, albeit taken with
> >good reason.
>
> The fundamental difference that I can think of is the inability to
> mix graphics and text, like for example putting a graphical border around
> the text window or to let text float around an image. And these can
> be quite a killer factor if you want, say, a game window that
> looks like an illuminated manuscript, with initials and miniatures and
> borders, or one that looks like the archaeologist's diary in "Beetmonger".

The Encyclopedia Frobozzica did that in Zork Zero. Lots of the subgames
did as well (see
http://www.bracey-griffith.freeserve.co.uk/Zip2000/DFanucci.png ), but they
could also have been done by breaking the background picture into lots of
subparts and using lots of windows, if absolutely necessary (as long as
window borders are invisible). Again, a graphical backing store is required.
The simplest way to extent Glulx to handle it would be to allow text to be
drawn in graphics windows. But that would not be a minor extension, and as
soon as people start extending Glulx, the compatiblity problems begin...

The only catch in V6 is that text is printed on a solid background colour, so
you can't overlay pleasantly on a textured background. A few of us V6 gurus
are quietly working behind the scenes on a minor standard extension which
would allow that.

M. D. Krauss

unread,
Nov 28, 2001, 9:00:58 AM11/28/01
to
On Wed, 28 Nov 2001 12:15:43 GMT
Kevin Bracey <kevin....@pace.co.uk> wrote:

> In message <9u290l$5sj$4...@news.lth.se>
> m...@df.lth.se (Magnus Olsson) wrote:
>
> > Shouldn't it be possible to compile glulxe and CheapGlk on most
> > systems with a standard C compiler? Or at least on Posix compliant
> > systems?
>
> Yes, I've managed cheapglk, except I haven't sorted out its file handling.
> I bet a lot of Glk programs won't like RISC OS' filenaming system though.

Huh? The more you talk about RISC OS the more intrigued I get. Just what
is it's filenaming system?

[Snip]

> The only catch in V6 is that text is printed on a solid background colour, so
> you can't overlay pleasantly on a textured background. A few of us V6 gurus
> are quietly working behind the scenes on a minor standard extension which
> would allow that.

Cool... That would be really snazzy.

You know, though, after all this discussion on z6 and Glulx and the quirks
of design involved in bringing essentially more dynamic display
capabilities and multimedia to IF, the more I think that HTML-TADS has the
right approach. I haven't used TADS so I'm not sure how it works, but HTML
and CSS combined already accomplish just about everything that everyone
wants for IF, and good open-source code is available for every major
platform for handling it correctly. So why bother re-inventing the wheel?

For platforms that don't want to go to the extent of a full HTML/CSS
system, those standards are designed very carefully so that anything that
is unimplemented will not seriously damage the presentation, which solves
another major pitfall involved here.

Couldn't an authoring system use the Gecko rendering engine (I'm not sure
how many platforms Gecko is available on?) for it's i/o? And if Gecko
isn't available on your platform of choice, a more primitive engine will
do -- the standard would be W3C HTML/CSS, not any particular
implementation.

I'm just brainstorming there, and I've been up since 11am yesterday, and
it's 9am now here. So if I've said anything stupid all apologies in
advance!

-M

(*YAWN*)

--
To email me convert my address to something resembling reason

Magnus Olsson

unread,
Nov 28, 2001, 10:04:23 AM11/28/01
to
In article <20011128090058.0bd2...@home-nospam.com-nospam>,

M. D. Krauss <MDKraus...@home-nospam.com-nospam> wrote:
>You know, though, after all this discussion on z6 and Glulx and the quirks
>of design involved in bringing essentially more dynamic display
>capabilities and multimedia to IF, the more I think that HTML-TADS has the
>right approach.

While I have only programmed in vanilla TADS, and never in HTML TADS,
I can at least say that I'm extremely impressed by the visual
appearance of some HTML TADS games; even if you discount such things
as screen resolution, I think they look just as good as the best V6
games. I don't know, though, how good HTML TADS is for doing things
like menus where you move around a highlight with the cursor keys.

Glulx games, on the other hand, tend to have a rather blocky
appearance, since Glk forces text and graphics into different windows.

Matthew Russotto

unread,
Nov 28, 2001, 10:38:09 AM11/28/01
to
In article <20011128090058.0bd2...@home-nospam.com-nospam>,
M. D. Krauss <MDKraus...@home-nospam.com-nospam> wrote:
>
>You know, though, after all this discussion on z6 and Glulx and the quirks
>of design involved in bringing essentially more dynamic display
>capabilities and multimedia to IF, the more I think that HTML-TADS has the
>right approach. I haven't used TADS so I'm not sure how it works, but HTML
>and CSS combined already accomplish just about everything that everyone
>wants for IF, and good open-source code is available for every major
>platform for handling it correctly. So why bother re-inventing the wheel?

CSS is an abomination. Also I'm unaware of any good open-source code for
it, particularly on the Mac.

OKB -- not okblacke

unread,
Nov 28, 2001, 10:37:43 AM11/28/01
to
m...@df.lth.se (Magnus Olsson) wrote:
>I may seem like I'm nitpicking, but I really don't think Glulx,
>or even Glulx Inform, should be referred to as a new authoring
>system. When people are talking about "Switching from Inform to
>Glulx" they make it sound like it's a really big step, which it
>isn't.

Yes. This confusion seems to be at the root of many misunderstandings.

>>Have
>>a single system that says "pick me!" to new authors and
>>that is truly convincing to the entire community.
>
>Bleargh. I suppose you want just one make of car on sale, and
>one brand of toothpaste?

Next we'll owe our souls to the company store. :-)

OKB -- not okblacke

unread,
Nov 28, 2001, 10:44:31 AM11/28/01
to
"Kevin Bracey" ke...@bracey-griffith.freeserve.co.uk wrote:
>Now, if everyone pulled their
>finger out and wrote a Glulx interpreter for every platform that currently
>has a Z-machine, we'd be laughing. Maybe one day. And then, interestingly,
>Glulx would lose one of its advantages for authors - at present there's near
>total uniformity in the interpreters that people use; they don't have to
>worry too much at the moment about screen size issues etc.

I think it's just the opposite. I personally have only used 2 Glulx
terps, but my understanding is that there is an IMMENSE variation in capability
from one platfrom to another. Some terps support sound, graphics, multiple
windows, mouse input, text styling, and the kitchen sink. Some apparently do
not support anything but a single window with plain, unvarnished text in it.
Now, some of these differences arise from the platform's Glk library rather
than the interpreter itself, but if, as you say, we look at it from an author's
perspective (and believe me, I do), there are untold differences between
various implementations.

>Even relatively simple things
>like menu systems that use proportional fonts are totally beyond it. Some of
>these restrictions will probably be lifted by later versions, others are
>fundamental parts of deliberate compromises in its design, albeit taken with
>good reason.

This isn't true, unless you're talking about some particular kind of menu
(and even then it probably isn't true). "Stick it to the man" uses a menu with
a proportional font (or at least, the menu is set up for a proportional font --
the interpreter may allow the player to set his font of choice, which may be
fixed-width).

OKB -- not okblacke

unread,
Nov 28, 2001, 10:46:06 AM11/28/01
to
m...@df.lth.se (Magnus Olsson) wrote:
>The fundamental difference that I can think of is the inability to
>mix graphics and text, like for example putting a graphical border around
>the text window or to let text float around an image. And these can
>be quite a killer factor if you want, say, a game window that
>looks like an illuminated manuscript, with initials and miniatures and
>borders, or one that looks like the archaeologist's diary in "Beetmonger".

Well, it is possible to have images "inline" with text in a text buffer
window (e.g., the main story window), although I can't say how this might be
dealt with on various terps.

Kevin Bracey

unread,
Nov 28, 2001, 10:31:57 AM11/28/01
to
In message <20011128090058.0bd2...@home-nospam.com-nospam>

M. D. Krauss <MDKraus...@home-nospam.com-nospam> wrote:

> Huh? The more you talk about RISC OS the more intrigued I get. Just what
> is it's filenaming system?

"." as the directory separator, case-insensitive filenames, no file
extensions. Files have an auxiliary filetype internally represented as a
12-bit number (a bit like the Mac). Many older disc formats only support
10-character leafnames.

A canonical path name might look like:

ATAFS::KBracey.$.Infocom.Games.ZorkZero

Where ATAFS: specifies the filing system, :KBracey specifies the drive, $
specifies the root directory. As with most systems, you can give partial
filenames like ":KBracey.Infocom", "$.Foo", "^.Blorb.Spec", "RAM:$.Blah".

There are lots of neat tricks like path variables being built into the basic
filing system API, so you can ask for things like:

Font:Trinity.Medium

where Font$Path is a system variable giving a comma-separated list of
directories to search.

Usually the approach to ported programs is to quietly swap "/" and "." before
calling the underlying system ("/" is legal in a filename).

In development environments, the compilers etc silently map "fred.h" to
"h.fred" so you put all your sources in a "c" directory, abject files in an
"o" directory, etc.


> I haven't used TADS so I'm not sure how it works, but HTML
> and CSS combined already accomplish just about everything that everyone
> wants for IF, and good open-source code is available for every major
> platform for handling it correctly. So why bother re-inventing the wheel?

Isn't HTML-TADS model basically the same as Glulx's? Does it actually allow
full arbitrary cursor movement? I'm something of an Inform bigot, so I'm not
that familiar with TADS. I did do a basic character mode port of the standard
runtime to RISC OS a while back though.

> Couldn't an authoring system use the Gecko rendering engine (I'm not sure
> how many platforms Gecko is available on?) for it's i/o? And if Gecko
> isn't available on your platform of choice, a more primitive engine will
> do -- the standard would be W3C HTML/CSS, not any particular
> implementation.

Well, I think it was rather Zarf's idea that Glk be a portable I/O system for
IF authoring systems. Only glulx is using it at the moment though. When I
have time I'm going to have a go at implementing the glk API in V6 Z-code, so
authors could use that API in the Z-machine too.

Andrew Plotkin

unread,
Nov 28, 2001, 10:54:56 AM11/28/01
to
Magnus Olsson <m...@df.lth.se> wrote:

> The fundamental difference that I can think of is the inability to
> mix graphics and text, like for example putting a graphical border around
> the text window or to let text float around an image. And these can
> be quite a killer factor if you want, say, a game window that
> looks like an illuminated manuscript, with initials and miniatures and
> borders, or one that looks like the archaeologist's diary in "Beetmonger".

Hang on, I added the ability for text to flow around (square) images.
You can do Z0-style manuscript capitals/miniatures.

You can put borders around a window with other windows. The
inter-window borders do show up -- that's something I'm thinking
about.

Adam Thornton

unread,
Nov 28, 2001, 10:56:11 AM11/28/01
to
In article <9u27kd$16q$1...@newsg1.svr.pol.co.uk>,
Kevin Bracey <ke...@bracey-griffith.freeserve.co.uk> wrote:
>Glulx would lose one of its advantages for authors - at present there's near
>total uniformity in the interpreters that people use; they don't have to
>worry too much at the moment about screen size issues etc.

I have but one word for you:

Ha.

Adam

Magnus Olsson

unread,
Nov 28, 2001, 10:59:21 AM11/28/01
to
In article <e5c08ee04...@kbracey.cam.pace.co.uk>,

Kevin Bracey <kevin....@pace.co.uk> wrote:
>Well, I think it was rather Zarf's idea that Glk be a portable I/O system for
>IF authoring systems. Only glulx is using it at the moment though.

Glulx is (currently) the only system where Glk is callable directly
from the VM. But Glk is used by several interpreters for other systems
(hiding it from the VM) - Nitfol springs to mind, and there are Glk-
based Alan and Hugo interpreters as well. And there's also Zarf's
C port of Dungeon, that calls Glk directly from C.

>When I
>have time I'm going to have a go at implementing the glk API in V6 Z-code, so
>authors could use that API in the Z-machine too.

Sounds like a lot of work for a very small gain to me.

Magnus Olsson

unread,
Nov 28, 2001, 11:00:48 AM11/28/01
to
In article <9u31cg$45m$1...@news.panix.com>,

Andrew Plotkin <erky...@eblong.com> wrote:
>Magnus Olsson <m...@df.lth.se> wrote:
>
>> The fundamental difference that I can think of is the inability to
>> mix graphics and text, like for example putting a graphical border around
>> the text window or to let text float around an image. And these can
>> be quite a killer factor if you want, say, a game window that
>> looks like an illuminated manuscript, with initials and miniatures and
>> borders, or one that looks like the archaeologist's diary in "Beetmonger".
>
>Hang on, I added the ability for text to flow around (square) images.
>You can do Z0-style manuscript capitals/miniatures.
>

Great! I've managed to miss that - sorry.

Andrew Plotkin

unread,
Nov 28, 2001, 11:01:00 AM11/28/01
to
Kevin Bracey <kevin....@pace.co.uk> wrote:
> In message <9u290l$5sj$4...@news.lth.se>
> m...@df.lth.se (Magnus Olsson) wrote:

>> Shouldn't it be possible to compile glulxe and CheapGlk on most
>> systems with a standard C compiler? Or at least on Posix compliant
>> systems?

> Yes, I've managed cheapglk, except I haven't sorted out its file handling.
> I bet a lot of Glk programs won't like RISC OS' filenaming system though.

Glk programs don't get much of a say in file naming. The library deals
with that. That was a design restriction I put in, for this precise
reason -- RiscOS was one of the cases I wanted to be compatible with.

(There's the fileref_create_by_name call, but the spec is really clear
that the Glk program should stick to 8-character filenames without
punctuation -- so that the library can add suffixes, or not, as
appropriate.)

Sheesh, people complain when I try to be OS-neutral, and they complain
when I don't. :-)

Kevin Bracey

unread,
Nov 28, 2001, 11:13:59 AM11/28/01
to
In message <9u31kp$c3p$1...@news.lth.se>
m...@df.lth.se (Magnus Olsson) wrote:

> > When I have time I'm going to have a go at implementing the glk API in V6
> > Z-code, so authors could use that API in the Z-machine too.
>
> Sounds like a lot of work for a very small gain to me.

A lot of people's main complaint about V6 is that it's too complicated,
whereas they seem quite happy driving Glk. So providing the Glk API in the
Z-machine would be one way of placating those people. Indeed, simple things
like big drop caps (a la Zork Zero) are a lot easier to ask for in Glk then
they are to code in V6.

It shouldn't be that hard, as the interpreter's doing most of the work. All I
have to do is map Glk concepts onto V6 concepts. Sort of Nitfol in reverse.

I think it's got more chance of being usable than trying an attempt to map
Glk onto V6, because of the helpful simplifying rules of Glk, and the
ultimately free-form graphical nature of V6.

Magnus Olsson

unread,
Nov 28, 2001, 12:01:02 PM11/28/01
to
In article <fb9992e04...@kbracey.cam.pace.co.uk>,

Kevin Bracey <kevin....@pace.co.uk> wrote:
>In message <9u31kp$c3p$1...@news.lth.se>
> m...@df.lth.se (Magnus Olsson) wrote:
>
>> > When I have time I'm going to have a go at implementing the glk API in V6
>> > Z-code, so authors could use that API in the Z-machine too.
>>
>> Sounds like a lot of work for a very small gain to me.
>
>A lot of people's main complaint about V6 is that it's too complicated,
>whereas they seem quite happy driving Glk. So providing the Glk API in the
>Z-machine would be one way of placating those people. Indeed, simple things
>like big drop caps (a la Zork Zero) are a lot easier to ask for in Glk then
>they are to code in V6.

Yes, but what I meant by the gain being small is that if you're using
the Glk API, then you can't use the V6 features that aren't in Glk,
right? Or are you planning some sort of "extended Glk"?

Lewis Raszewski

unread,
Nov 28, 2001, 12:50:39 PM11/28/01
to
Kevin Bracey wrote:
>
> "Matthew Russotto" <russ...@wanda.pond.com> wrote in message
> news:u07pmco...@corp.supernews.com...
> > In article <9u0nrd$oih$1...@news.lth.se>, Magnus Olsson <m...@df.lth.se>
> wrote:
> > >On the other hand, how many platforms have full implementations of
> > >the V6 Z-machine? One, if I understand things correctly.
> >
> > Five. Of course, you'll have to encode your files in Infocom format
> > to use the other four. (Apple IIgs, Mac, Amiga, PC)
>
> I am half-seriously considering writing a Blorb->MG1 converter, tragically.
> Stop me before it's too late.
>
> There is a minor gotcha, in that the interpreters for those platforms are of
> course commercial products, so you'd have to pay for them. But in the
> absence of any freeware alternative...

>
> I was lead to believe by the Z-Spec that Frotz did V6. What's missing?
>
> What about V6 on handhelds? V6, even with graphics, should be possible on
> many current handhelds, especially considering that Infocom made do with
> 320x200 displays. And even without graphics, reasonable fallbacks should be
> possible. Anyone looking at this? Or Glulx on handhelds?
>
> > Though I admit I'm starting to get motivated to put some Blorb support
> > into the V6 Zip Infinity and release it on an experimental basis.
> > Just starting, though.
>
> Feel free to rip as much code as you like out of Zip 2000, or to contact me
> with any queries.

Frotz supports not blorb. Linux frotz also fails to support sound or
graphics of any kind (afaik)

--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407

"This is the noise that keeps me awake; my head explodes and my body
aches."
-- Garbage, Push It

Lewis Raszewski

unread,
Nov 28, 2001, 12:57:26 PM11/28/01
to
Jaap van der Velde wrote:

> Well, I guess, but the main reason for my asking "Why?"
> was my wondering about yet another 'new' system. I think
> IF would be really helped by a few authoring systems
> kicking the bucket and more people jumping on the right
> bandwagon. If Inform/z-machine is essentially dead (as
> in not going to change to allow for larger or more complex
> games), I think it would be wise to slowly abandon it. But
> I'd hate to have to look back in five years and conclude
> we should have staid put.
>

Why? Games aren't getting bigger. z8 will still accomodate games far
larger than have every been written for it. At a guess, I'd suspect that
there have been something like six games *ever* which patently could not
be shoehorned into the z-machine.

Glulx does not run on handhelds, and probably will not for the near
future. Glulx barely runs on DOS, and will not run on the wacky 8-bits
that float around here.


> Well, as you can guess, I'd rather think of it as a
> definitive replacement instead of an alternative. I think
> IF has been 'blessed' with *enough* alternatives. It's time
> to eliminate some of the alternatives in my opinion. Have
> a single system that says "pick me!" to new authors and
> that is truly convincing to the entire community. This
> includes offering some sort of friendly IDE in the long
> run to authors that don't want to be programmers.
>

I'm still, I gather, the only person who finds it ironic that everyone
wants a graphical tool for writing text games.

> Point is: if everything Z-code has to offer is covered by
> Glulx as well, what possible reason could any author of
> IF have to pick Z? Sure there are more interpreters out
> there but is a 5-minute download really going to stop
> anyone? And if Glulx takes almost all z games, why not
> recompile (nearly) all of them and offer them as Glulxe-
> playable games as well. This will convince every reader
> without an interpreter to select Glulxe as his prefered
> download instead of some Frotz. No offense intended, I
> really enjoy WinFrotz. And of course, I would like to
> see a Glulxe for my Palm, but that's a whole 'nother
> story.
>

Glulx game files are larger than equivalent Z-code. The interpreter runs
more slowly. THe screen model is substantially more complex.
I could go on.


--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407

"'Till now, I always got by on my own -- I never really cared until I
met
you." -- Heart, Alone

Kevin Bracey

unread,
Nov 28, 2001, 12:31:55 PM11/28/01
to
In message <9u31ns$45m$2...@news.panix.com>
Andrew Plotkin <erky...@eblong.com> wrote:

> Kevin Bracey <kevin....@pace.co.uk> wrote:
>
> > Yes, I've managed cheapglk, except I haven't sorted out its file
> > handling. I bet a lot of Glk programs won't like RISC OS' filenaming
> > system though.
>
> Glk programs don't get much of a say in file naming. The library deals
> with that. That was a design restriction I put in, for this precise
> reason -- RiscOS was one of the cases I wanted to be compatible with.

It's appreciated :)

> (There's the fileref_create_by_name call, but the spec is really clear
> that the Glk program should stick to 8-character filenames without
> punctuation -- so that the library can add suffixes, or not, as
> appropriate.)
>
> Sheesh, people complain when I try to be OS-neutral, and they complain
> when I don't. :-)

Oh, Glk's fine. It's authors that are going to be the problem. I've got a big
design decision to make - do I treat filenames as RISC OS ones and pass them
straight through, which was your intent, or do I do a Unix->RISC OS type
mapping in case some muppet has put an extension or directory separator in?

I'd rather do the former, but I can't help but feel that it'll break in
practice. I suppose as long as the spec is clear, which I think it is, RISC
OS users would be justified on jumping on any authors who do anything silly.

Lewis Raszewski

unread,
Nov 28, 2001, 1:28:34 PM11/28/01
to
Magnus Olsson wrote:

> >I think
> >IF has been 'blessed' with *enough* alternatives. It's time
> >to eliminate some of the alternatives in my opinion.
>
> And just how do you propose to do that?
>

Dear Mr. President,
There are too many authoring systems nowadays. Please eliminate three.
I am not a kook.

Signed,
Abe Simpson

--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407

Squirrel -- It's the other gray meat.

Lewis Raszewski

unread,
Nov 28, 2001, 1:41:18 PM11/28/01
to
"M. D. Krauss" wrote:
>
> On Wed, 28 Nov 2001 12:15:43 GMT
> Kevin Bracey <kevin....@pace.co.uk> wrote:
>
> > In message <9u290l$5sj$4...@news.lth.se>
> > m...@df.lth.se (Magnus Olsson) wrote:
> >
> > > Shouldn't it be possible to compile glulxe and CheapGlk on most
> > > systems with a standard C compiler? Or at least on Posix compliant
> > > systems?
> >
> > Yes, I've managed cheapglk, except I haven't sorted out its file handling.
> > I bet a lot of Glk programs won't like RISC OS' filenaming system though.
>
> Huh? The more you talk about RISC OS the more intrigued I get. Just what
> is it's filenaming system?
>
Ever downloaded inform?

Ever noticed that the standard inform library files don't have .h's at
the ends of their names?

RISC OS doesn't let you put a period in a file name. I think it uses it
as the directory separator.



> You know, though, after all this discussion on z6 and Glulx and the quirks
> of design involved in bringing essentially more dynamic display
> capabilities and multimedia to IF, the more I think that HTML-TADS has the
> right approach. I haven't used TADS so I'm not sure how it works, but HTML
> and CSS combined already accomplish just about everything that everyone
> wants for IF, and good open-source code is available for every major
> platform for handling it correctly. So why bother re-inventing the wheel?
>

I'm not entirely convinced. Aside from the fact that there would almost
certainly be no console mode version of such an interpreter, the
web-formatting languages are, by and large, designed for static
documents. There's a basic uneasiness with using that sort of thing in a
system where text is beign printed at any time from various places. It
would take an insane amout of checking to prevent disrupting the screen
model by sending a HTML code at the wrong time.

Also, I think there's somethign fundamentally "not quite right" about
confabulating formatting information and printed text (in a game. In a
static doument, it makes more sense).

--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407

"The color of the sky, as far as I can see, is cold gray." -- 10,000
Maniacs,
Like the Weather