[Glk] Text styles and fonts
Andrew Plotkin
My life is dull (with the usual moments of sheer terror), so I think I'll
start picking interface arguments.
I'm working on this Glk idea, which ideally will take care of all the
interface and porting problems for IF systems, at least for the next few
years. Optimistic, but I'm trying.
I'm still evolving the design. Here's one question: what kind of options
should be available for text styles and fonts?
For comparison, the Z-machine has normal, fixed-width, bold, and
underlined/italic styles. (It also has some provision for specialized
fonts, but this is only used for the rune font in Beyond Zork, and it's
not really defined past the point of "do what we need in this one game.")
One extreme answer would be: nothing. The game can only produce text; it
has no control over how the text appears; that's entirely the province of
the interpreter.
The opposite extreme is: everything. The game can specify a font (by
name), a font size, foreground and background color, left/right/center
justification, and individual character positioning for subscripts and
overstrikes.
I hope it's obvious that I'm looking for something in between these two
extremes. :-) On the one hand, it should be possible for interpreter
writers to handle the full range of game options without going insane --
and that includes interpreters running in terminal emulation windows. On
the other hand, this is intended to support existing IF systems and
future ones, and I don't want to cramp them.
Hm, this is a tricky post, because I can see some replies that go off
down the wrong track and I want to head them off.
"Why not use HTML?" No, that's not the question. HTML is a syntax for
specifying formatting. I want to decide what formatting should be
*specifiable*. (As it happens, I'm casting Glk as a programming API, not
a text-stream format. Although it would be perfectly possible to write
code to parse HTML or HTML-like text into Glk API calls. But, as I said,
that's not my topic here.)
"Why not say that you can specify any formatting, and the interpreter will
implement as much as it can?" This sounds great. In practice, it's gotten
us the Web, and "This page is best viewed with Interscape 5.9.9; the rest
of you can lick my pallid buttocks." There is also, for example, no
portable way whatsoever to specify fonts. (Every platform has its *own*
portable way, really. Grn.) And also -- this leaves no room whatsoever for
player preferences. I *like* player preferences.
Suggestion One:
Decide on a fixed list of display styles -- by *usage*, not by how they
look. For example:
Normal / body text
Emphasized
Fixed-width
Note
Alert
Heading / chapter title
Subheading / section title
That's seven styles, with a bit of variation, but still a group that you
can hold in your hand and look at. If you see what I mean. :)
It is entirely up to the interpreter to decide how these are
distinguished. "Heading" could be 18-point and "subheading" 14-point; or
it could be red versus green, or bold versus underlining. Different
indenting levels. Or so on. A polite interpreter will allow player
preferences to control all of this.
("Fixed-width" is of course an exception -- the interpreter has to
guarantee that it really is fixed-width -- but this is a practical
necessity.)
(It is quite possible that a particular interpreter will not be able to
display all seven styles distinguishably. A monochrome VT320 terminal only
*has* bold, underlined, and reverse text, and distributing the styles to
the combinations of those is more confusing than helpful. And of course
all the fonts on such a terminal are fixed-width, so "normal" and
"fixed-width" will look the same. If your game really needs the player to
be able to see particular styles, it's not impossible. There will be a Glk
API call to test which styles are distinguishable.)
Enough typing for now. What do people think? What do authors want? (I
know, I know, authors want everything. You know, most of the Web is
*ugly*.)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Daryl McCullough
In article <erkyrathE...@netcom.com>, erky...@netcom.com says...
>Decide on a fixed list of display styles -- by *usage*, not by how they
>look. For example:
>
> Normal / body text
> Emphasized
> Fixed-width
> Note
> Alert
> Heading / chapter title
> Subheading / section title
A different topic, but what I want to know is how you got the cool
lightning effects in _A Change in the Weather_. Pretty neat special
effect for a text game.
Daryl McCullough
CoGenTex, Inc.
Ithaca, NY
Joe Mason
In article <erkyrathE...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
>
>Decide on a fixed list of display styles -- by *usage*, not by how they
>look. For example:
>
> Normal / body text
> Emphasized
> Fixed-width
> Note
> Alert
> Heading / chapter title
> Subheading / section title
This sounds like the most interesting. I'm brought in mind of the TADS
"indentation vs. spacing" paragraph debate - I think the best solution to that
was to have the author mark "paragraph break" and let the interpreter pick how
to display it.
However, I'm a little worried that authors will start assuming that these look
the same on all systems. HTML has the same type of thing: instead of letting
the author pick font sizes directly, it has header sizes defined as "H1", "H2",
etc. The individual browser decides what size to make it. But as far as I
know, every browser except Lynx displays the different headers in the exact
same way, giving the temptation for authors to use them for formatting that
otherwise might not work on all browsers.
The obvious antidote to this is to make a couple of interpreters implement
these categories completely differently, so that authors simply couldn't
depend on them for formatting details.
Joe
David A. Cornelson
In article <erkyrathE...@netcom.com>,
erky...@netcom.com (Andrew Plotkin) wrote:
>
> My life is dull (with the usual moments of sheer terror), so I think I'll
> start picking interface arguments.
>
>
> Emphasized
> Fixed-width
> Note
> Alert
> Heading / chapter title
> Subheading / section title
>
Hmmm, this is interesting. I believe formatting text is important and
although we're talking about strictly text games, there is a lot to be
desired. There are certainly platfroms that would allow more flexibility
than others so you're already faced with dual or mulitple standards.
For myself, highlighting and placement are probably the most important.
Easily formatting text to indent, left, center, right, making rows and
columns, using platform specific abilities (fonts) would be nice.
Other than that I would have to suggest a Pan-Galactic Gargle Blaster or
two to break up the monotony.
David A. Cornelson, Chicago
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Andy Leighton
On Tue, 6 Jan 1998 07:28:14 GMT, Andrew Plotkin <erky...@netcom.com> wrote:
>"Why not use HTML?" No, that's not the question. HTML is a syntax for
>specifying formatting. I want to decide what formatting should be
>*specifiable*.
Well properly HTML does not specify formatting, it has nothing to
do with format it is content markup (pretty much as your 7 styles
below). However it has been sorely abused in the past and I
believe the fight to be already lost.
>Decide on a fixed list of display styles -- by *usage*, not by how they
>look. For example:
>
> Normal / body text
> Emphasized
> Fixed-width
> Note
> Alert
> Heading / chapter title
> Subheading / section title
>
>That's seven styles, with a bit of variation, but still a group that you
>can hold in your hand and look at. If you see what I mean. :)
How about a conversation style as well?
Well from what you have suggested I believe you are very close to
Berner-Lee's original idea for HTML. The problem is going to be
trying to stop people abusing the system, are we going to get games
with comments such as
"best played with body text set to Times New-Roman 12 etc etc."
or more likely "set Note style to Wingdings".
--
Andy Leighton => an...@azaal.dircon.co.uk
"... January is your third most common month for madness" - _Sarah Canary_
Algernon Petrofsky
erky...@netcom.com (Andrew Plotkin) writes:
> "Why not use HTML?" No, that's not the question. HTML is a syntax for
> specifying formatting. I want to decide what formatting should be
> *specifiable*.
Okay, I'll rephrase the question, "Why not provide the same set of
markup elements as HTML?". The answer, I think, is that that set is a
little bigger than what you were thinking of providing. So my next
question is "Why not provide a simplified subset of the HTML markup
elements?", and that seems to be about what you proposed.
You might want to consider also allowing separate style commands a la
web style sheets. Then the game can specify that a piece of text
should be emphasized, and that the emphasis should preferably be
indicated by using the color red. The interpreter and/or player could
override one or both of these directives.
-al
Daniel Shiovitz
In article <erkyrathE...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
>My life is dull (with the usual moments of sheer terror), so I think I'll
>start picking interface arguments.
Life: a semi-interactive parody
> Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.Z.PANIC.
You win!
(with a little work, this game can be adapted to produce "Essay: an
interactive writing-a-term-paper")
[..]
>of you can lick my pallid buttocks." There is also, for example, no
>portable way whatsoever to specify fonts. (Every platform has its *own*
>portable way, really. Grn.) And also -- this leaves no room whatsoever for
>player preferences. I *like* player preferences.
[..]
> Normal / body text
> Emphasized
> Fixed-width
> Note
> Alert
> Heading / chapter title
> Subheading / section title
As a player, yeah, I like player preferences, but as an author I hate
'em. Seriously, how much does it add to the playing experience to be
able to tell the interpreter "Display whatever text the author chose
to call 'Header' text in 18-point bold"? I don't want to try and hold
back the Formatting Revolution here, but IMO the reason the web looks
so crappy is because interpreters have so much freedom in how to
interpret code that it's impossible for designers to design anything
that looks nice cross-platform. Bleah. I would be perfectly happy to
stick with bold, italic, underline, fixed. If I want to emphasize
something, I'll make it bold, or if I want to emphasize it a different
want I'll italicize it. (Plus, if you let authors ask "does this
interpreter distinguish style X from style Y?" I bet you'll end up
with them effectively using bold-italic-fixed anyway. Oh, um, it does
occur to me it might be nice sometimes for authors to provide a font
with the game, and then be able to say "display this text in
MyFont". Is that feasible? This certainly wouldn't be terribly clean,
and I can see some formatting problems if the provided font is, say,
half the size of whatever the user's set the default text to, but
still ...
(The one thing that HTML gets right, which I hope makes it into GLK,
is being able to specify formatting tags that the interpreter doesn't
necessarily understand. That's a good thing.)
Other stuff:
Left/right/center/justify alignment seems pretty necessary. Er.. I was
going to ask about multi-column printing, but then I started thinking
that under the current setup, the proper way to handle this would be
wth multiple windows. Yes?
>--Z
--
(Dan Shiovitz) (d...@cs.wisc.edu) (look, I have a new e-mail address)
(http://www.cs.wisc.edu/~dbs) (and a new web page also)
(the content, of course, is the same)
William R Sherman
In article <erkyrathE...@netcom.com>, erky...@netcom.com (Andrew Plotkin) writes:
> My life is dull (with the usual moments of sheer terror), so I think I'll
> start picking interface arguments.
>
> ("Fixed-width" is of course an exception -- the interpreter has to
> guarantee that it really is fixed-width -- but this is a practical
> necessity.)
>
> (It is quite possible that a particular interpreter will not be able to
> display all seven styles distinguishably. A monochrome VT320 terminal only
> *has* bold, underlined, and reverse text, and distributing the styles to
> the combinations of those is more confusing than helpful. And of course
> all the fonts on such a terminal are fixed-width, so "normal" and
> "fixed-width" will look the same.
I just have this one small comment to this thread regarding the
previous statement:
Actually, back in the old everything was fixed-width days, there still
was a distinction between even and right-justified spacing, so the
implementor of an interpreter that used only fixed with fonts could
still differentiate between fixed-width and "normal" using these
two methods.
> If your game really needs the player to
> be able to see particular styles, it's not impossible. There will be a Glk
> API call to test which styles are distinguishable.)
>
> Enough typing for now. What do people think? What do authors want? (I
> know, I know, authors want everything. You know, most of the Web is
> *ugly*.)
Yep, I'm aware of that. I argued in the pre-Netscape days of Mosaic
that there should at least be some extra parameters for Images to
allow them to have captions, and even be able to specified their
relationship to how text flowed around them. I thought this would
be a good comprimise, but it didn't pan out (and I wasn't forceful
enough).
> --Z
Bill
/*************************************************************************/
/* Bill Sherman (wshe...@ncsa.uiuc.edu) */
/* National Center for Supercomputing Applications */
/* University of Illinois at Urbana-Champaign */
/* Og - "You want to do mankind a real service? Tell funnier jokes" */
/* Spinner - "but facts don't always reveal the truth" */
/* Robin - "Yeah, but I always figure that's the writers' fault" */
/*************************************************************************/
Christopher James Brown
> Decide on a fixed list of display styles -- by *usage*, not by how they
> look. For example:
>
> Emphasized
> Fixed-width
> Note
> Alert
> Heading / chapter title
> Subheading / section title
I like this idea a lot...And someone mentioned a "conversation" style,
which I think might be useful. You could make it so the programmer can
define these styles, but the user has the option to override them. Also,
perhaps a utility could be created that would allow the programmer to test
their code on virtual displays of other computers/interpreters...A VT100
display, a XVGA display, and Amiga 640x200 16 colour display,
etc...therefore allowing the programmer to see with his/her own eyes how
their set-up will look on other machines...Lastly, perhaps you could put an
option for multiple setups as seperate files, therefore if the programmer
was lazy (or if a new interpreter arrives on a new machine later on), then
someone who has that particular computer/interpreter can create a display
set-up which works well enough for that platform...I don't know if I am
making any sense, but hopefully I am...
Jason Brown
Andrew Plotkin
Andy Leighton (an...@azaal.dircon.co.uk) wrote:
> On Tue, 6 Jan 1998 07:28:14 GMT, Andrew Plotkin <erky...@netcom.com> wrote:
> >specifying formatting. I want to decide what formatting should be
> >*specifiable*.
> Well properly HTML does not specify formatting, it has nothing to
> do with format it is content markup
Sorry, I was unclear in making my point; I said "formatting" when I meant
"any text attributes".
HTML is a text-based syntax for specifying stuff. I want to decide what
stuff is specifiable; I'm not worrying about making a text-tag syntax to
specify it.
Andrew Plotkin
Joe Mason (jcm...@undergrad.math.uwaterloo.ca) wrote:
> In article <erkyrathE...@netcom.com>,
> Andrew Plotkin <erky...@netcom.com> wrote:
> >
> >look. For example:
> >
> > Normal / body text
> > Emphasized
> > Fixed-width
> > Note
> > Alert
> > Heading / chapter title
> > Subheading / section title
> This sounds like the most interesting. I'm brought in mind of the TADS
> "indentation vs. spacing" paragraph debate - I think the best solution to that
> was to have the author mark "paragraph break" and let the interpreter pick how
> to display it.
I was considering going that far myself -- but life is easier if there's
a pure text layer underneath the styles. And in the text layer,
newline or double-newline has to indicate a paragraph break.
It's not that I dislike the way HTML does it; I just want to make the
style mechanism purely optional.
> However, I'm a little worried that authors will start assuming that these look
> the same on all systems.
I'm hoping that forward momentum will prevent that. I get to release the
first display library, for the Mac, and that *will* have full player
control of style formatting. Plus, the *second* display library will be
for the generic terminal window (via curses.h), and that is limited to
underline/bold/reverse no matter what. Pilot and Newton versions are also
limited. Hopefully authors will understand that this is a major slice of
the market.
Andrew Plotkin
Daniel Shiovitz (d...@coyote.cs.wisc.edu) wrote:
> As a player, yeah, I like player preferences, but as an author I hate
> 'em. Seriously, how much does it add to the playing experience to be
> able to tell the interpreter "Display whatever text the author chose
> to call 'Header' text in 18-point bold"?
You'd be surprised. I really dislike colored text, for example; even when
I use it, I turn it to much more muted colors than the populace seems to
prefer. If the game controls color, I'm guaranteed to be pissed off.
Do you like IF room names to be printed in bold? (I'm thinking that would
be a common use for the "subheader" style.) Would you rather have each
game's author choose whether to make room names bold, or choose it
yourself for all games?
> Oh, um, it does
> occur to me it might be nice sometimes for authors to provide a font
> with the game, and then be able to say "display this text in
> MyFont". Is that feasible?
It's very, very hard. It certainly won't be in the first version. There is
no way to provide a font which can be used by Mac, Windows, X, Pilot
(assuming the Pilot even has fonts, I don't know.)
> (The one thing that HTML gets right, which I hope makes it into GLK,
> is being able to specify formatting tags that the interpreter doesn't
> necessarily understand. That's a good thing.)
Yes. The fundamental API call is glk_set_style(style, value), and if the
interpreter doesn't recognize style (or can't handle it), nothing happens.
> Left/right/center/justify alignment seems pretty necessary.
Why? I see that just about everybody is requesting it, and I'm not
unwilling, but what would you use it for?
The most obvious use is to center headers. But I think that should be
done by using the "header" style, and allowing that the player may decide
whether headers are centered or not.
> Er.. I was
> going to ask about multi-column printing, but then I started thinking
> that under the current setup, the proper way to handle this would be
> wth multiple windows. Yes?
Yes.
There's no way to have a single text stream that flows through multiple
columns, but I think that's too complicated to support.
Andrew Plotkin
Christopher James Brown (c.b...@utoronto.ca) wrote:
> I like this idea a lot...And someone mentioned a "conversation" style,
> which I think might be useful.
Huh. I'm antsy about it. There already are typographic conventions for
conversations, and this means that some authors will inevitably just use
them (as they do with TADS/Inform) and not bother with the "conversation"
style. Then you have inconsistency again.
> You could make it so the programmer can
> define these styles, but the user has the option to override them.
Right. Style sheets, or rather style hint sheets.
On the one hand this allows players the freedom to waive their freedom to
control the display. That accords with my principles.
On the other hand, if many interpreters default to following the style
hints, authors will learn to expect that they are controlling formatting
instead of content; this is *exactly* what happened to HTML. I'm afraid
that eventually this will lead to newbies asking "What does header style
look like?" and people answering "Eighteen-point, bold, and centered.
Except for weenie interpreters and you don't have to care about them."
> Also,
> perhaps a utility could be created that would allow the programmer to test
> their code on virtual displays of other computers/interpreters...
Good idea, but a tremendous amount of work. (Can you imagine trying to
write portable *virtual platform-native display* code? Eww.)
Someone else can do it. I want to concentrate on getting Glk itself defined
and then implemented.
Joe Mason
>
>Why? I see that just about everybody is requesting it, and I'm not
>unwilling, but what would you use it for?
>
>The most obvious use is to center headers. But I think that should be
>done by using the "header" style, and allowing that the player may decide
>whether headers are centered or not.
Poetry comes to mind. In fact, the necessity of printing poetry (which I will
probably end up doing fairly often if I ever get around to writing more games)
will make me demand some sort of text control beyond specifying paragraph
styles: I like to play with spacing and indentation to play with rhythmic flow.
Joe
Damien Neil
On Wed, 7 Jan 1998 19:00:22 GMT, Andrew Plotkin <erky...@netcom.com> wrote:
>> You could make it so the programmer can
>> define these styles, but the user has the option to override them.
>
>Right. Style sheets, or rather style hint sheets.
An idea just came to me.
Allow the author to define styles. If an author desires to print chapter
headings in a specific style, she may define a [header] style, with some
default definition -- a hint, as you say. The user may then reconfigure
the definition of the style to his heart's content.
Flexibility, extensibility, and freedom. The author may suggest, the
reader may object, and both can be happy.
>On the one hand this allows players the freedom to waive their freedom to
>control the display. That accords with my principles.
Same here. I'll go a step further: presentation makes a difference. I
would say that my enjoyment of _Freedom and Necessity_ was heightened by
the wonderful physical quality of the hardback edition I read it in, for
example. (Not that it wouldn't have been a staggeringly beautiful story
if read off of scribbled notes written on dirty napkins.) While
portability is vital, and the reader should always have the choice to
deviate from the author's preferences, the author should at least be
allowed to take a fair shot at typesetting her work to the best degree
possible.
>On the other hand, if many interpreters default to following the style
>hints, authors will learn to expect that they are controlling formatting
>instead of content; this is *exactly* what happened to HTML. I'm afraid
>that eventually this will lead to newbies asking "What does header style
>look like?" and people answering "Eighteen-point, bold, and centered.
>Except for weenie interpreters and you don't have to care about them."
This could be a problem, I will grant. On one hand, some the first Glk
implementations will be terminal-based programs with barely any formatting
abilities at all. On the other hand, the same can be said of HTML. On
the snout hand, the IF community is probably never going to grow to a size
where old hats will overlook newbies in need of a clue transfusion.
- Damien
JC
On Tue, 6 Jan 1998 07:28:14 GMT, erky...@netcom.com (Andrew Plotkin)
wrote:
[...]
>
>HTML is a syntax for specifying formatting.
HTML is, or at least was, intended to specify structure, not formatting.
Of course, hardly anyone uses it that way.
';';James';';
Patrick Kellum
In article <EMFKH...@undergrad.math.uwaterloo.ca>, Joe Mason was talking about:
>Poetry comes to mind. In fact, the necessity of printing poetry (which I will
>probably end up doing fairly often if I ever get around to writing more games)
>will make me demand some sort of text control beyond specifying paragraph
>styles: I like to play with spacing and indentation to play with rhythmic flow.
I'm not quite sure what the point of Glk is, but all these text formating
styles (yes, even centering and right-justification) are easy with
standard Inform.
Patrick
---
A Title For This Page -- http://www.syix.com/patrick/
Bow Wow Wow Fan Page -- http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page -- http://smallwonder.simplenet.com/
My Arcade Page -- http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Berry
Daniel Shiovitz
I think my general feeling on this stuff is that I don't like authors
making "suggestions" to the interpreter. As an author, this usually
doesn't give me enough power to control how it looks; as a player, I
have the same problem from the other side. That said:
In article <erkyrathE...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
>Daniel Shiovitz (d...@coyote.cs.wisc.edu) wrote:
>
>> As a player, yeah, I like player preferences, but as an author I hate
>> 'em. Seriously, how much does it add to the playing experience to be
>> able to tell the interpreter "Display whatever text the author chose
>> to call 'Header' text in 18-point bold"?
>
>You'd be surprised. I really dislike colored text, for example; even when
>I use it, I turn it to much more muted colors than the populace seems to
>prefer. If the game controls color, I'm guaranteed to be pissed off.
Ok, so strike color from the list of things that the author can
set. This means I can't illustrate a game about the rainbow-colored
smurves of HappyLand properly, but that's a risk I'm willing to
take. Or here's an alternative that I could live with (which I think
is pretty similar to what we have now, and not at all similar to HTML):
let interpreters control whether or not authors can set color. If the
interpreter says "Yes, I'll use the game-provided color scheme" then
the game has total control over the color, including how bright to
make it and what precise shade of red to use. If the interpreter says
"No, I won't use the game-provided color scheme", then the game has no
control over the color, and all its "setcolor" commands are
ignored. This reduces the environments a programmar has to develop for
to two: with color, and without color. If the game supports color,
then the programmer can be sure that the color will adhere to the
following guidelines, and all the following functions will work
properly to modify the color. If the game doesn't support it, the
programmer can either deal or say "well, fine, you can't run my game
then".
I like this because it limits the views I have to code for, grants me
a lot of flexibility as a programmer, but also lets me as a player
turn off color if it looks horrid.
>Do you like IF room names to be printed in bold? (I'm thinking that would
>be a common use for the "subheader" style.) Would you rather have each
>game's author choose whether to make room names bold, or choose it
>yourself for all games?
In this case, I'd prefer to let the game author handle it, because
then they can do tricks with the highlighting if it makes the game
work better (dunno what.. maybe bold room names during daytime and
un-bold at night). But again.. I suppose you ould have an interpreter
flags "game controls formatting of subheader? Y/n"
[..]
>> Left/right/center/justify alignment seems pretty necessary.
>
>Why? I see that just about everybody is requesting it, and I'm not
>unwilling, but what would you use it for?
Er.. um.. what if I had a game set in mirror-land, and so I had two
parallel windows running up-down on the screen, and displayed the room
descriptions left-aligned in the left window, and did the same
descriptions but backwards and right-aligned in the right window?
Important, vital game issues like that.
It occurs to me also I'd like to be able to do concrete poetry ala the
mouse's tail poem from Alice in Wonderland. Is this doable currently?
(hmm.. you could almost do it with just fixed width, but what if the
display wasn't wide enough?)
Patrick Kellum
In article <691vma$h...@spool.cs.wisc.edu>, Daniel Shiovitz was talking about:
>I think my general feeling on this stuff is that I don't like authors
>making "suggestions" to the interpreter. As an author, this usually
>doesn't give me enough power to control how it looks; as a player, I
>have the same problem from the other side. That said:
I'm begining to have some serious probs with Glk. From the looks of it AP
wants all text adventures to look exactally the same. There goes
individuality. I personally like using colour in games, f Mr. Plotkin
doesn't like that then he can turn it off, I belive his interpreters don't
support colour anyway. I don't see why we need this added code to
interpreters, HTML is screwed up as it is, I would think we would all
learn from that mistake.
>Er.. um.. what if I had a game set in mirror-land, and so I had two
>parallel windows running up-down on the screen, and displayed the room
>descriptions left-aligned in the left window, and did the same
>descriptions but backwards and right-aligned in the right window?
>Important, vital game issues like that.
Simple in Inform but it looks imposable with Glk.
>It occurs to me also I'd like to be able to do concrete poetry ala the
>mouse's tail poem from Alice in Wonderland. Is this doable currently?
>(hmm.. you could almost do it with just fixed width, but what if the
>display wasn't wide enough?)
Using a combination of fixed font pieces and a few simple routines (check
out the example for centering text in the Designers manual for a good
start) and this is very doable. As long as the screen is as wide as the
longest piece of text (something that would be required anyway) this
should work just fine. (this is in Inform, I don't know enough about the
other languages to say).
Jeff Hatch
Andrew Plotkin wrote:
[snip]
> I'm working on this Glk idea, which ideally will take care of all the
> interface and porting problems for IF systems, at least for the next few
> years. Optimistic, but I'm trying.
>
> I'm still evolving the design. Here's one question: what kind of options
> should be available for text styles and fonts?
Time permitting, I'd like to make my system Glk-compatible. Beyond the
interface issues we've already discussed, I have just two concerns about
your Glk specifications.
1. Pop-up windows, such as quotations. These are fairly popular, and
they don't belong in the standard output stream. Do you have a way to
handle these?
2. Error message text. I think it might be nice someday to have an
interpreter that erases error messages (and the accompanying) commands
after the error's been resolved, leaving the persistent view of the game
unimpeded by misspellings. I'm not doing anything like that
myself--heck, I haven't even implemented a status line yet!--but a
different display type for errors seems like it could be a good idea,
just in case.
Come to think of it, though, I could already implement the second one
just by automatically undoing any error-causing move just before the
next move gets made, since my Undo feature scrolls the screen in
reverse. I'll have to think this over more.
-Rúmil
Andrew Plotkin
Patrick Kellum (pat...@syix.com) wrote:
> In article <EMFKH...@undergrad.math.uwaterloo.ca>, Joe Mason was talking about:
> >Poetry comes to mind. In fact, the necessity of printing poetry (which I will
> >probably end up doing fairly often if I ever get around to writing more games)
> >will make me demand some sort of text control beyond specifying paragraph
> >styles: I like to play with spacing and indentation to play with rhythmic flow.
> I'm not quite sure what the point of Glk is, but all these text formating
> styles (yes, even centering and right-justification) are easy with
> standard Inform.
Not centering and right-justification, not in the story window. Trust me
on this. :)
The point of Glk is porting games that aren't written for existing
portable systems (TADS and Inform.)
Joe Mason
In article <34B491...@hatch.net>, Jeff Hatch <je...@hatch.net> wrote:
>1. Pop-up windows, such as quotations. These are fairly popular, and
>they don't belong in the standard output stream. Do you have a way to
>handle these?
I'll second that!
>2. Error message text. I think it might be nice someday to have an
>interpreter that erases error messages (and the accompanying) commands
>after the error's been resolved, leaving the persistent view of the game
>unimpeded by misspellings. I'm not doing anything like that
>myself--heck, I haven't even implemented a status line yet!--but a
>different display type for errors seems like it could be a good idea,
>just in case.
This should be fairly simple - use the standard DOS/Unix convention of having
a "standard output" and "standard error" stream. Interpreters are free to
have a separate window to print errors, mix them with game text, ignore them,
print them in a different colour, log them to a file, etc.
Joe
Patrick Kellum
In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:
>Not centering and right-justification, not in the story window. Trust me
>on this. :)
Subtract the length of the text (divided by 2) from the width of the
screen (in characters, divided by 2). To get the width of the screen in
proporational fonts take the width of the "0" character and use that as
the character width (standard practice).
There, you've got centered text. The only prob with proporational
characters is it mght be off center very slightly, but it still looks
fine.
Right-justifed and percentage-Justfied text s very east to work out from
there.
>The point of Glk is porting games that aren't written for existing
>portable systems (TADS and Inform.)
Oh, ok. I thought it was a proposed change in the text capabilities of
Inform and other already existing systems.
Mark J Musante
Patrick Kellum (pat...@syix.com) wrote:
> screen (in characters, divided by 2). To get the width of the screen in
> proporational fonts take the width of the "0" character and use that as
> the character width (standard practice).
I beg to differ. In the two OSs I write code for (Windows & PalmOS),
there are functions available to tell you the *exact* width of a string,
no matter what font you're using. I have never used the technique you
describe above.
-=- Mark -=-
John Wood
[Delurking - hi all! I won't be around much, but I'm trying to get back
into recreational computing a little.]
Andrew Plotkin <erky...@netcom.com> wrote,
> I'm working on this Glk idea, which ideally will take care of all the
> interface and porting problems for IF systems, at least for the next
> few years. Optimistic, but I'm trying.
>
> I'm still evolving the design. Here's one question: what kind of
> options should be available for text styles and fonts?
[...]
> Suggestion One:
>
>Decide on a fixed list of display styles -- by *usage*, not by how they
>look.
Sensible.
> For example:
>
> Normal / body text
> Emphasized
> Fixed-width
> Note
> Alert
> Heading / chapter title
> Subheading / section title
These need to be organised into orthogonal sets. For instance, text
cannot be both a heading and a subheading, but it can be emphasised and
fixed-width. I'm not entirely clear on the meaning of "note" and
"alert", but one arrangement would be
Style
Normal / body text
Heading / chapter title
Subheading / section title
Note
Font
Normal
Fixed-width
Emphasis
Normal
Emphasised
Alert
So each piece of text would have one style, one font and one emphasis.
Once you have a draft list that you feel happy with, it's worth looking
back at existing games and checking you can handle them elegantly. For
instance, what options would an interpreter specify to display boxes
(like the Trinity quotes), or the status line, or the bold location name
present in most z-games?
A related issue is character sets, but you probably don't want to get
that discussion tangled with this one...
John
Patrick Kellum
In article <EMIs7...@world.std.com>, Mark J Musante was talking about:
>I beg to differ. In the two OSs I write code for (Windows & PalmOS),
>there are functions available to tell you the *exact* width of a string,
>no matter what font you're using. I have never used the technique you
>describe above.
And how does it do this (getting a common width for all characters in a
proporitional font)? I would guess it does the same thing I mentioned, I
don't see any other way. A "0" is the widest character in a font, any
other method would cause some characters to be partialy overwritten with
the following characters.
Andrew Plotkin
Patrick Kellum (pat...@syix.com) wrote:
> In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:
> >Not centering and right-justification, not in the story window. Trust me
> >on this. :)
> Subtract the length of the text (divided by 2) from the width of the
> screen (in characters, divided by 2). To get the width of the screen in
> proporational fonts take the width of the "0" character and use that as
> the character width (standard practice).
> There, you've got centered text. The only prob with proporational
> characters is it mght be off center very slightly, but it still looks
> fine.
Well, you can do that in Glk; I am allowing you (with some misgivings.
:-) to measure the width of the window (measured in "0" characters.)
It's icky, and in proportional fonts it tends to be far off the
centerline, since spaces are much narrower than zeroes.
> >The point of Glk is porting games that aren't written for existing
> >portable systems (TADS and Inform.)
> Oh, ok. I thought it was a proposed change in the text capabilities of
> Inform and other already existing systems.
Well, that too, in a sense. I really want to get a Glk version of Hugo,
eventually. And if there is ever a serious update to the Z-machine --
32-bit memory and so on -- it should *not* stick with the existing
Z-machine I/O system (either V5/8 or V6.)
Andrew Plotkin
Jeff Hatch (je...@hatch.net) wrote:
> Time permitting, I'd like to make my system Glk-compatible. Beyond the
> interface issues we've already discussed, I have just two concerns about
> your Glk specifications.
> 1. Pop-up windows, such as quotations. These are fairly popular, and
> they don't belong in the standard output stream. Do you have a way to
> handle these?
I'd do it by opening a new window, below the status window, and keep it
open until the next player input. That's easy in the current API.
> 2. Error message text. I think it might be nice someday to have an
> interpreter that erases error messages (and the accompanying) commands
> after the error's been resolved, leaving the persistent view of the game
> unimpeded by misspellings. I'm not doing anything like that
> myself--heck, I haven't even implemented a status line yet!--but a
> different display type for errors seems like it could be a good idea,
> just in case.
There's no backup-and-delete in a stream window; they're output only. But
you could have a second window for errors.
Andrew Plotkin
Daniel Shiovitz (d...@coyote.cs.wisc.edu) wrote:
> they can do tricks with the highlighting if it makes the game
> work better (dunno what.. maybe bold room names during daytime and
> Er.. um.. what if I had a game set in mirror-land, and so I had two
> parallel windows running up-down on the screen, and displayed the room
> descriptions left-aligned in the left window, and did the same
> descriptions but backwards and right-aligned in the right window?
> Important, vital game issues like that.
Yeah, it tends to wind up like that. Strained cases. *Yes*, they can have
legitimate uses -- but I'm more concerned with portability and ease of
implementation.
> It occurs to me also I'd like to be able to do concrete poetry ala the
> mouse's tail poem from Alice in Wonderland. Is this doable currently?
> (hmm.. you could almost do it with just fixed width, but what if the
> display wasn't wide enough?)
If the display isn't wide enough, you're screwed anyway, right?
Andrew Plotkin
> Allow the author to define styles.
Headache! Pain! Also, it cuts the player out of the loop. You don't ask
the player to set a bunch of styles options every time they start playing
a new game.
I'll stick with a fixed list.
I do believe I'll stick one or two "user" styles on the list, though.
Andrew Plotkin
Patrick Kellum (pat...@syix.com) wrote:
> I'm begining to have some serious probs with Glk. From the looks of it AP
> wants all text adventures to look exactally the same.
I want them all to look the same when *I* play them. That's different.
> >Er.. um.. what if I had a game set in mirror-land, and so I had two
> >parallel windows running up-down on the screen, and displayed the room
> >descriptions left-aligned in the left window, and did the same
> >descriptions but backwards and right-aligned in the right window?
> >Important, vital game issues like that.
> Simple in Inform but it looks impossible with Glk.
Actually, if I can modify my earlier post, it's *not* safely possible in
Inform in the story window, because if the story window / status window
size differentiation which I've talked about before.
Andrew Plotkin
Ok, let me explain what I'm getting at here.
I want a system which is *easy* to port. That's why I'm keeping all the
interface specifications abstract. I want something which can be
implemented with existing text objects (Java's text thingie, Mac's
TextEdit, curses.h, whatever thingies are used by the Pilot and Newton.)
This means that I do not want a system which allows the game author to do
anything. The more the author can do, the more the porter *has* to do.
Look at the V6 Z-machine. It has, what is it, arbitrary code which can be
run at each line break? I've never even considered implementing it.
Now, on the author hand -- I meant to write "other hand", but I'll leave
it :-) -- there's nothing wrong with style hints which the interpreter
can take or leave. That doesn't make porting harder.
Here's the current version of the plan.
There is a fixed list of styles:
Normal / body text
Emphasized
Fixed-width
Note
Alert
Heading / chapter title
Subheading / section title
Block quote
User style 1
User style 2
Note that each piece of text is in exactly one of these styles. You can't
have "fixed-width emphasized" text. This is a deliberate simplification.
I could have gone for a perfect disjunction between formatting
(fixed-width, emphasized) and structure (heading, block-quote.) I think
it would be too large a pain, and bring up too many icky questions. Just
pretend that all of these are structural attributes. (Maybe I should
rename "fixed-width" to "preformatted"?)
Some of these styles may wind up looking the same, and there is an API
call to detect this. In particular, the two user styles could be almost
anything, including identical to the "normal" style.
(Also note that in a status window, all of these styles are still
available -- the only difference is that you're guaranteed that they're
all fixed-width, with the same character width. Of course, in a status
window, the "normal" and "fixed-width" styles are probably going to look
the same.)
You (the game author) can provide hints on how the styles will look. The
hints can include color, justification, indentation, size (relative --
from -3 to +3, or something like that), weight (is it bold?), emphasis
(is it italicized/underlined?), and proportionality. Specifying a font by
name is way too uncertain, I'm afraid, and I think I won't touch it with
a long pole.
These hints are per window. If you have two windows, you can request that
emphasized text be red in one window and blue in the other. (Or left and
right justified, or whatever.)
This brings up a sticky problem -- what happens if you change a style
hint after some text has already been printed? Honestly, I may make this
illegal or let the results be undefined. (I want to allow interpreters to
use very simple print-and-forget I/O. That is, nothing in the Glk spec
forces interpreters to be able to redraw or reformat their windows.)
(In fact, it would be easiest to say that windows store their style hints
when they are created, and can never be changed thereafter. The problem
with this is that Glk starts up with the main window already created; I
wanted a standard output stream to be available, so that simple programs
wouldn't have to deal with window handling at all.)
Patrick Kellum
In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:
>> Oh, ok. I thought it was a proposed change in the text capabilities of
>> Inform and other already existing systems.
>Well, that too, in a sense. I really want to get a Glk version of Hugo,
?!?! So we're going to completly wipe out an entire system of text
adventures just to make it easer to port to Macs?
>eventually. And if there is ever a serious update to the Z-machine --
>32-bit memory and so on -- it should *not* stick with the existing
>Z-machine I/O system (either V5/8 or V6.)
What, if I may ask, is wrong with the existing Z-Machine I/O? It has
worked fine and it appears to support everything you want and much more.
Patrick Kellum
In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:
>Jeff Hatch (je...@hatch.net) wrote:
>> 1. Pop-up windows, such as quotations. These are fairly popular, and
>> they don't belong in the standard output stream. Do you have a way to
>> handle these?
>
>I'd do it by opening a new window, below the status window, and keep it
>open until the next player input. That's easy in the current API.
Goody, a screen full of windows. Why not just draw a quote box in the
current window like Frotz does with Informs "box" code?
Patrick Kellum
In article <erkyrath...@netcom.com>, Andrew Plotkin was talking about:
>I want them all to look the same when *I* play them. That's different.
Well, why should I bother to create any adventures when I can't even be
allowed to say how they should work. Again, this is an interpreter issue,
not a language issue, not an author issue. If you don't want to allow
bold text then dont, if you want to use a large font then do. I don't see
any reason we should all switch to a more limited (read, lowest common
denominator) system of text output when a properly written interpreter can
do everything you're asking.
>> Simple in Inform but it looks impossible with Glk.
>
>Actually, if I can modify my earlier post, it's *not* safely possible in
>Inform in the story window, because if the story window / status window
>size differentiation which I've talked about before.
That was a problem with your interpreter, NOT with Inform. Your
interpreter can't set the header bits properly, fix the interpreter to
support version 1.0 (or even 0.2 for that matter) of the Z-Machine
standard and it will work fine. The method s OK, it works on all
standard-compatable interpreters.
Patrick Kellum
In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:
>This means that I do not want a system which allows the game author to do
>anything. The more the author can do, the more the porter *has* to do.
Now this is absured, why don't we just make all games work on a Commodore
Vic-20, anything that doesn't run on a Vic-20 can't be allowed. Lowest
Common Denominator is not the way to go. Yes, games should be compatable
with a wide range of machines, but that is allready the case. Inform 5
games run fine on old C64 machines and I see no reason that with a few
edits to the C64 interpreter that V8 games couldn't be supported (or even
V6 with a total interpreter re-write). The porter should work at the
port, no one said programming was easy. Sacrificing author options is NOT
needed just to make a few lazy porters happy. In the end the porters will
be able to port to many machines but at a great cost, the games will be
limited. Currently, I could write Supper Mario Brothers in Inform, that s
how powerful the language s. If Glk becomes the standard then we might as
well just start writing games in Basic again, that s how constrained the
authors will be (even more so, I would thank).
>Look at the V6 Z-machine. It has, what is it, arbitrary code which can be
>run at each line break? I've never even considered implementing it.
This code is very important for creating fancy text layout. For instance,
if I had a christmas tree image on the screen and I wanted to flow the
text around the image I would use this great feature. Wth Glk I couldn't
do that, I would be stuck with some ugly seperate window with a tree in
it. Ugly and totally 80s.
Just because you can't be bothered to add support for it in your
interpreter doesn't mean everyone else doesn't want it. As I remember,
your interpreter doesn't even support set_colour, something that EVERY
other interpreter supports. Does this mean that we should all stop using
set_colour? Seems kinda aragent to me.
>Note that each piece of text is in exactly one of these styles. You can't
>have "fixed-width emphasized" text. This is a deliberate simplification.
Why not? What s so wrong with fixed-width + emphasized? It is easy to
write an interpreter that supports it. And if the interpreter doesn't
support it then it can ignore one.
[ very limited I/O system sniped ]
So, we should no longer support half of what the Z-Machine supports.
Before, if a machine didn't support bold text it could do something
different with the text. If emphisied text was to be printed, the
interpreter could print it in italics, underline it, or print it in a
different colour (or a hundred other things). AmigaFrotz allows the
player to choose fonts, emphisis style (underline or italics), screen
size, colours, etc. This does everything your standard does but still
allows everything the Z-Machine allows for. This can be done for ANY
interpreter on ANY system if the interpreter author was willing to spend a
few hours at the keyboard.
So, yes I do not care for the Glk standard. To me it's just a way to
limit IF authors just to make it easer to port to the Mac. If the Mac
doesn't allow editing on the text screen then so be it, that shouldn't
mean that every other system out there should be required to follow this
limitation.
Julian Arnold
> Patrick Kellum (pat...@syix.com) wrote:
> > >Er.. um.. what if I had a game set in mirror-land, and so I had two
> > >parallel windows running up-down on the screen, and displayed the room
> > >descriptions left-aligned in the left window, and did the same
> > >descriptions but backwards and right-aligned in the right window?
> > >Important, vital game issues like that.
>
>
> Actually, if I can modify my earlier post, it's *not* safely possible in
> Inform in the story window, because if the story window / status window
> size differentiation which I've talked about before.
You could do it in Hugo. :)
Jools
--
"For small erections may be finished by their first architects; grand
ones, true ones, ever leave the copestone to posterity. God keep me from
ever completing anything." -- Herman Melville, "Moby Dick"
Julian Arnold
In article <erkyrathE...@netcom.com>, Andrew Plotkin> [...]
> (Also note that in a status window, all of these styles are still
> available -- the only difference is that you're guaranteed that they're
> all fixed-width, with the same character width. Of course, in a status
> window, the "normal" and "fixed-width" styles are probably going to look
> the same.)
I'll go read your Glk specs later (meaning tomorrow), but for now, a
question. What do you mean by "a status window." Does Glk assume the
limited Z-machine approach to windows (where you can have two, one a
text stream and one non-word wrapping and fixed width-only, with the
first below the second), or would it allow a more flexible approach like
Hugo's (multiple non-overlapping windows, all word wrapping and
scrollable), or what?
Patrick Kellum
In article <34bf6906...@news.virgin.net>, Steve Waddicor was talking about:
>If the string is "This" it adds the width of the T to the width of the
>h to the width of the i ...
This is not the same thing.
>No, an M is conventionally the widest character in a font. That's why
>the unit for measuring widths in a font is an 'em'. The W is wider
>than the O too.
"0", not "O", i.e. Zero, not Ohhhh.
Andrew Plotkin
I'm combining my reponses to a few different posts here.
Julian Arnold (jo...@arnod.demon.co.uk) wrote:
> > (Also note that in a status window, all of these styles are still
> > available -- the only difference is that you're guaranteed that they're
> > all fixed-width, with the same character width. Of course, in a status
> > window, the "normal" and "fixed-width" styles are probably going to look
> > the same.)
> I'll go read your Glk specs later (meaning tomorrow), but for now, a
> question. What do you mean by "a status window."
You can have multiple non-overlapping windows. Each one can be a text
stream window or a text-grid window -- essentially the difference between
story and status windows in the Z-machine.
Eventually I'll define other types of windows, such as a graphics window.
Patrick Kellum (pat...@syix.com) wrote:
> In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking
about:
> [quote boxes]
> >I'd do it by opening a new window, below the status window, and keep it
> >open until the next player input. That's easy in the current API.
>
> Goody, a screen full of windows. Why not just draw a quote box in the
> current window like Frotz does with Informs "box" code?
Because that puts all sorts of requirements on the capabilities of the
current window.
The way I have it set up, you can implement a text-stream window with
very little more than printf(). The interpreter never *has* to back up,
edit, redraw, or format. As I said, you can use a Mac TextEdit object.
The *only* methods of a text-stream window are "print some text",
"input a line", "input a key", "clear", "measure size", and "change
style". (And that last one is optional.)
If I added a requirement to be able to show quote boxes, then we're
talking about a much more complicated object. Overlaying a rectangle
of fixed-width text in a Mac TextEdit thing is hard -- you have to
store all the extra text yourself, scroll it along with the TextEdit
scrolling, and so on.
The same goes for the Win95 and Java text objects -- just so that you
don't think Macs are the issue here.
As to the rest of your posts, uh, I think you're *completely* missing the
point of what I'm doing.
I'm trying to design a system which includes as much as possible of the
Z-machine's interface, *and* expand it as much as possible, while *still*
being implementable on a C-64.
That means making all the fancy stuff (1) optional and (2) easy to factor
out -- so that it's not intertwined with the basic capabilities. You can
do quote boxes, but they're kept separate from the regular text stream.
You can do styles, but the formatting can be overridden or ignored by the
interpreter. You can do graphics, but (again) in a separate window, not
mixed in with text -- least in the first version. (If it becomes clear
that more is necessary, Glk can be extended without breaking existing
programs that use it.)
For heaven's sake, I'm implementing this with the same display engine I
used for MaxZip. I didn't remove *anything* from its capabilities; the
style system will be made considerably more powerful.
Miron Schmidt
Patrick Kellum <pat...@syix.com> wrote:
> In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:
>
> >anything. The more the author can do, the more the porter *has* to do.
>
> Now this is absured, why don't we just make all games work on a Commodore
> Vic-20, anything that doesn't run on a Vic-20 can't be allowed. Lowest
> Common Denominator is not the way to go.
Uh, but he isn't talking about any lowest common denominator: He's talking
about not allowing authors to do highly system-dependent stuff -- such as
specifying font names, or formatted-font-specific-colored styles etc.
The *user* on the other hand, may specify any options the port on his/her/its
system allows. That's the way I understood it, at least.
> The porter should work at the
> port, no one said programming was easy.
A porter is not programming anything -- he is porting a program from one
system to another. The whole point of the Glk specification is to make that
as easy as possible.
> Currently, I could write Supper Mario Brothers in Inform,
Now *there's* a game I'd really like to see! Will there be Dinner Mario
Brothers, too?
> that s
> how powerful the language s.
Well, I'm sure you know that isn't true. Action games with 10 fps suck. And
since the Z-Machine doesn't provide interrupts, 10 fps is the maximum you'll
be able to get. Write some complicated code between frames and you'll end at
1 fps.
> If Glk becomes the standard then we might as
> well just start writing games in Basic again, that s how constrained the
> authors will be (even more so, I would thank).
Glk is not an authoring system, or a programming language.
> Just because you can't be bothered to add support for it in your
> interpreter doesn't mean everyone else doesn't want it. As I remember,
> your interpreter doesn't even support set_colour, something that EVERY
> other interpreter supports.
Glk is not an interpreter, or a programming language.
The *author* suggests a text style, the *player* defines what this style will
look like in effect.
> So, yes I do not care for the Glk standard. To me it's just a way to
> limit IF authors just to make it easer to port to the Mac. If the Mac
> doesn't allow editing on the text screen then so be it, that shouldn't
> mean that every other system out there should be required to follow this
> limitation.
It seems to me that these reservations result widely from the fact that you
don't understand the Glk concept (either that, or I don't -- perfectly
imaginable).
Nobody is restraining anyone here. The central point to the concept is that
text games are, well, text games. Formatting text is something entirely
different than layouting text: it is not necessary to define the exact look
of the text; it is only necessary to stress some points. The author says,
"That one word is important: I emphasize it" -- the user in turn defines what
emphasis, to him, means. The author says, "Look, it's important that this
letter is written in a non-proportional font: There's a column code in it."
-- the user then gets to choose his own favourite non-proportional font. AND
she can set the color for that font, and that it should be printed in
italics.
Something like HTML, really. Only more restrained in order to *clarify* the
situation for the author.
--
Miron Schmidt <mi...@comports.com> PGP key on request
WATCH TV... MARRY AND REPRODUCE... OBEY... PLAY INTERACTIVE FICTION...
Patrick Kellum
In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:
>Because that puts all sorts of requirements on the capabilities of the
>current window.
Seems to work fine on all the interpreters I use. The code is simple from
the looks of it. If you can't write the code then don't draw the boxs in
the window. But don't require every other system to follow this
limitation.
>The way I have it set up, you can implement a text-stream window with
>very little more than printf(). The interpreter never *has* to back up,
>edit, redraw, or format. As I said, you can use a Mac TextEdit object.
>The *only* methods of a text-stream window are "print some text",
>"input a line", "input a key", "clear", "measure size", and "change
>style". (And that last one is optional.)
So it's a Mac limitation? Why should a limitation on the Mac require
every other system (even possable on a C64) to drop a standard feature.
>The same goes for the Win95 and Java text objects -- just so that you
>don't think Macs are the issue here.
Then how are the Win95 interpreters doing it now? Amigas handle it OK.
C64 machines can draw them just fine.
>As to the rest of your posts, uh, I think you're *completely* missing the
>point of what I'm doing.
Not really, although I may not always speek (type) with much clairity, I'm
quite capable of understanding your standard and it's hazards.
>I'm trying to design a system which includes as much as possible of the
>Z-machine's interface, *and* expand it as much as possible, while *still*
>being implementable on a C-64.
If it doesn't include all of the Z-Machines features without making any
changes to the Z-Machine then it is a step backwards.
How should we be creating windows in a C64?
>That means making all the fancy stuff (1) optional and (2) easy to factor
>out -- so that it's not intertwined with the basic capabilities. You can
>do quote boxes, but they're kept separate from the regular text stream.
>You can do styles, but the formatting can be overridden or ignored by the
>interpreter. You can do graphics, but (again) in a separate window, not
>mixed in with text -- least in the first version. (If it becomes clear
>that more is necessary, Glk can be extended without breaking existing
>programs that use it.)
This is what I have a problem with. You'are assuming that all systems are
limited in the same way. On a Commodore 64 I can have text boxes,
graphics, scrolling text, whatever in the same screen. Macs don't appear
to be up to this level I guess (of course that's wrong, but I'm making a
point here.)
Have you seen the StdIO ports of Frotz for text terminals? They seem to
be handeling text boxes and all that other "fancy" stuff just fine. And
they're just using printf (or its equavilent, I'll have to check).
Nothing fancy, it gnores what it can't display. Glk is not needed, if a
system can't use a feature then just ignore it.
>For heaven's sake, I'm implementing this with the same display engine I
>used for MaxZip. I didn't remove *anything* from its capabilities; the
>style system will be made considerably more powerful.
MaxZip can't even handle colours and doesn't come close to supporting the
Z-Machine standard. It is not something we should base all text
adventures on.
Now before everyone claims I hate Macs (some nasty emails over night) I
personally love Macs. I mearly using them in examples because the Glk
standard seems to be based around the Macs limitations.
Patrick Kellum
In article <34B77CAD.MD-...@tfh-berlin.de>, Miron Schmidt was talking about:
>Patrick Kellum <pat...@syix.com> wrote:
>> Now this is absured, why don't we just make all games work on a Commodore
>> Vic-20, anything that doesn't run on a Vic-20 can't be allowed. Lowest
>> Common Denominator is not the way to go.
>
>Uh, but he isn't talking about any lowest common denominator: He's talking
>about not allowing authors to do highly system-dependent stuff -- such as
>specifying font names, or formatted-font-specific-colored styles etc.
No, he wants to dis-allow authors from using features of the Z-Machine.
This is NOT system-dependent.
And he is talking lowest common denominator. If the Mac doesn't support a
feature then it is not allowed. That is the basis of Glk as I read it.
>A porter is not programming anything -- he is porting a program from one
>system to another. The whole point of the Glk specification is to make that
>as easy as possible.
Wrong! Have you ever ported something from one system to another? Unless
it uses a simple StdIO interface (printf and such) then it does require
massive programming. Take a look at the Amiga port of Frotz, the Amiga
specfic code is massive. When porting "The Night of the Vampire Bunnies"
to Inform I re-wrote almost every line of code. The only thing that
remains the same is the text. Same goes for all other game ports
(Adventure to Inform, I guess that only required a couple simple changes.
Nobody had to do any programming for that one.)
>> Currently, I could write Supper Mario Brothers in Inform,
>
>Now *there's* a game I'd really like to see! Will there be Dinner Mario
>Brothers, too?
Hah Hah :-) Ok, so typing while loaded with massive amounts of Caffine
isn't a good thing. BTW, my "i" key is brokin, so I can't be blaimed for
those errors :-)
>Well, I'm sure you know that isn't true. Action games with 10 fps suck. And
I started writting a Space Invaders port to Inform, got the alians moving
down at a steady pace and the player moving just fine. Only prob I was
having was reading the keys (had to only push one key at a time, I didn't
like that). The only reason I didn't finish it was I lost the source and
didn't feel like re-doing everything. Super Mario Bros. would be a lot of
work but it is possable. The original Mario Bros. would be even simpler.
>since the Z-Machine doesn't provide interrupts, 10 fps is the maximum you'll
Actually, in a way the V6 Z-Machine does.
>be able to get. Write some complicated code between frames and you'll end at
>1 fps.
I got about 10fps with Space Invaders. Not perfect but it worked. Free
Fall seems to play fine and it's the same basic idea.
>Glk is not an authoring system, or a programming language.
Acording to the author, he wants to incorporate Glk into Inform. That
makes it an authoring system.
>Glk is not an interpreter, or a programming language.
>The *author* suggests a text style, the *player* defines what this style will
>look like in effect.
This is already possable wthout Glk. Do you really belive that every
system out there handles bold text in the same manner?
>It seems to me that these reservations result widely from the fact that you
>don't understand the Glk concept (either that, or I don't -- perfectly
>imaginable).
I understand it, I just don't see a need for it. If I wanted to step
backwards I would use an 8088 machine.
>Nobody is restraining anyone here. The central point to the concept is that
No text boxes allowed in the same window. No pictures allowed except as
seperate windows. No editing of text in the window.
Nope, no restraints.
>text games are, well, text games. Formatting text is something entirely
>different than layouting text: it is not necessary to define the exact look
>of the text; it is only necessary to stress some points. The author says,
>"That one word is important: I emphasize it" -- the user in turn defines what
>emphasis, to him, means. The author says, "Look, it's important that this
>letter is written in a non-proportional font: There's a column code in it."
>-- the user then gets to choose his own favourite non-proportional font. AND
>she can set the color for that font, and that it should be printed in
>italics.
And the author is not allowed to say what colour the text should be.
Currently this is allowed in all properly-written interpreters.
>Something like HTML, really. Only more restrained in order to *clarify* the
>situation for the author.
This is my fear. I can just see it now "This game is for MaxZip. Go out
and get a real interpreter.".
HTML was great in the begining, but it has been perverted. HTML and
Interactive-Fiction are two totally different things. What happins when a
game written to ask for a "header font" is played on an older interpreter?
Brock Kevin Nambo
Patrick Kellum wrote in message <699ejb$l9u$1...@neko.syix.com>...
>HTML was great in the begining, but it has been perverted. HTML and
>Interactive-Fiction are two totally different things. What happins when a
>game written to ask for a "header font" is played on an older interpreter?
Nothing, because that should be the interpreter's setting...
Similar to HTML; the actual web page doesn't ask you what you want it to
look like, but you tell the browser, "show me what this page wants to look
like" or "I don't care what the page wants to look like, I want it to look
like this".. (ok, if you use lynx, you get less options. But Lynx's
formatting makes sense in "True" HTML.)
Uh, is that clear?
>>BKNambo
--
http://come.to/brocks.place | World Domination Through Trivia!
What games are on? Check out The Schedule!
http://members.xoom.com/mozilla/monster.html
oah123 (in chatquiz, 12/27/97): "did you guys know during the SPIN cycle the
clothes are like being spun really fast? LOL i just found that out!"
Damien Neil
On 11 Jan 1998 03:14:36 GMT, Patrick Kellum <pat...@syix.com> wrote:
>So it's a Mac limitation? Why should a limitation on the Mac require
>every other system (even possable on a C64) to drop a standard feature.
Hmm. Quote boxes are, unfortunately, the worst kind of feature: once
upon a time, there was a system which implemented things a certain way.
People took advantage of some of this system's idiosyncrasies. Now,
everyone is required to duplicate those same idiosyncrasies, even in
places where they make no sense at all.
Are you familiar with how quote boxes operate? To draw a quote box, one:
a) Resizes the status window to cover the area of the screen where the
quote box is to go.
b) Draws the quote box _in the status window_(!).
c) Resizes the status window back to its original size.
The assumption is that shrinking the status window is non-destructive.
Unfortunately, this is not going to be true in any system written for
a windowing environment, be it the Macintosh, MS-Windows, the X Windowing
System, or even lowly curses (assuming you use the curses windowing
features). Therefore, an interpreter writer is left with two choices:
ignore all windowing system support, and just write everything by hand,
or engage in nasty hacks involving status window size. (Xzip and (so
I hear) MaxZip take the latter approach, which appears to work tolerably
well.
> >The same goes for the Win95 and Java text objects -- just so that you
> >don't think Macs are the issue here.
>
>Then how are the Win95 interpreters doing it now? Amigas handle it OK.
>C64 machines can draw them just fine.
I have a strong suspicion that the Win95 interpreters are not using the
Win95 text objects. (I cannot say for sure, never having used a Win95
interpreter.) The C64 interpreters clearly are not using any native
text objects -- there aren't any. They also have a vastly simpler
situation to deal with, as they use only a fixed width font. Introducing
proportional fonts makes life vastly more interesting. (It also makes
using native windowing system services vastly more appealing, to reduce
the number of wheels that need to be reinvented.)
> >As to the rest of your posts, uh, I think you're *completely* missing the
> >point of what I'm doing.
>
>Not really, although I may not always speek (type) with much clairity, I'm
>quite capable of understanding your standard and it's hazards.
I'm a bit unclear on what these hazards are. As far as I can tell, Glk
offers a vastly more powerful output interface than the one currently
supported by the Z-machine (with the exception of graphics, which would
be easy enough to add into Glk's infrastructure). It seems that the only
Z-machine feature that anyone is using which Glk does not offer support
for is quote boxes overlayed onto a text window. Personally, I don't
consider this much of a loss -- I can recall playing Trinity, and having
quote boxes appear, covering text I hadn't read yet. Most annoying.
Furthermore, the manner in which a quote box should interact with a
scrollback buffer is most unclear to me.
>How should we be creating windows in a C64?
In, perhaps, the same fashion Infocom did? The concept of a window is
orthogonal to the concept of graphics. The Glk specification quite
clearly indicates that a window can be, for example, "the top two lines
of the screen".
>Now before everyone claims I hate Macs (some nasty emails over night) I
>personally love Macs. I mearly using them in examples because the Glk
>standard seems to be based around the Macs limitations.
You may wish to reexamine the Glk standard. After reading through it
several times (I'm still tempted to do a curses port -- however, today
I had _The Door Into Shadow_ to finish, and the copy of _Eight Skilled
Gentlemen_ I finally managed to locate arrived yesterday, so this weekend
is pretty much spoken for), I can see no aspect of it which seems to
cater to any Macintosh-specific limitations. Limitations of windowing
systems in general, perhaps -- but any such limitations apply equally
to Windows, Java's AWT, X, and others just as much as to the Macintosh.
- Damien
Bryan Scattergood
On 10 Jan 1998 05:18:32 GMT, Patrick Kellum wrote:
> >> Simple in Inform but it looks impossible with Glk.
> >
> >Actually, if I can modify my earlier post, it's *not* safely possible in
> >Inform in the story window, because if the story window / status window
> >size differentiation which I've talked about before.
>
> interpreter can't set the header bits properly, fix the interpreter to
> support version 1.0 (or even 0.2 for that matter) of the Z-Machine
> standard and it will work fine. The method s OK, it works on all
> standard-compatable interpreters.
No. No. No. You are reading guarantees into the standard which (IMHO) just
aren't there. Let me try and explain how I understand the screen model, and
how I ended up there.
The basic Z<6 model was based on fixed-width character-mapped displays.
Given such a display, the screen-size recorded in the header reflects the
screen size in characters. The height provides an upper bound on the size of
the upper window. The width indicates how many characters can be printed
across the upper window (in the status line, for example.) On such a
display, the extend-overprint-shrink behaviour used to do block quotes is
fairly natural: it just replaces the contents of some of the character cells
which 'really' belong to the lower window.
Now, come the early 1990s there were a number of DOS/UNIX based interpreter
cores around and folks were busy porting them to systems with proportional
fonts. It turned out that this wasn't too hard: use a proportional font for
the lower window where the interpreter controls the word-wrap, use a fixed
font for the upper window. The screen-size still represents the geometry in
terms of the fixed-font used for the upper window, because the the game
still needs to know (a) how tall it can make the upper window and (b) how
much it can print across the status-line. The size is *not* based on which
window is currently selected since some games expect to read the geometry
before selecting the upper window.
Block-quotes in this model are a pain because the upper and lower window are
using different fonts. A variety of solutions are possible. Putting the
status window in a separate host window is one. The proposed GLK-approach of
deferring the 'shrink' until character input is another. In my case I plot
the upper-window text over the flowed text in the lower window, keeping
track of which character cells in the upper window are transparent (having
never been printed.) It doesn't really matter which solution is used,
because the fact the two windows use different fonts is enough to break your
assumption that the screen-size tells you anything meaningful about the
lower-window.
Still not convinced? Even if you insist that I *have* to use the same basic
font for both windows, all you achieve is to make conformant interpreters
impossible on machines with small screens. (The Z-machine requires a minimum
upper window size of 64 columns by 16 rows. Some of the platforms which
currently have interpreters cannot meet that requirement, even using the
smallest font available. The only reasonable way to fake it is to make the
upper window larger than physical screen (which is larger than the lower
window) and to pan around the upper window. That breaks your assumption
again.)
Bryan
Bryan Scattergood
On 10 Jan 1998 05:11:24 GMT, Patrick Kellum wrote:
> >> Oh, ok. I thought it was a proposed change in the text capabilities of
> >> Inform and other already existing systems.
>
> >Well, that too, in a sense. I really want to get a Glk version of Hugo,
>
> ?!?! So we're going to completly wipe out an entire system of text
No. The GLK API (which is what Zarf is currently asking for feedback on) is
a layer which fits between an interpreter core and the host operating
system. If done properly that should allow an OS specific (GLK) module to be
written /once/ for each platform, after which any GLK-supporting interpreter
can be ported directly. And adding GLK support to an interpreter (Z-machine,
HUGO, TADS, AGT) also needs to be done only once. It is the classic benefit
from a suitable API; porting goes from an m*n to an m+n task.
Now, the API as it stands imposes one restriction on Z-machine interpreters:
block quotes can't be implemented quite as prettily as they are on some
current platforms (they have to disappear when input happens.) That may be a
shame, but as an interpreter maintainer I *can* tell you that the complexity
they add to the display code is considerable. Zarf has taken the decision
that the cost they add to porting GLK isn't worth the benefit.
> >eventually. And if there is ever a serious update to the Z-machine --
> >32-bit memory and so on -- it should *not* stick with the existing
> >Z-machine I/O system (either V5/8 or V6.)
>
> What, if I may ask, is wrong with the existing Z-Machine I/O? It has
> worked fine and it appears to support everything you want and much more.
If you need to ask ...
The Z-machine as-is provides two I/O models. The Z5 model is too
restrictive, with no scope for graphics or multiple text windows. The Z6
model is so complicated that I still don't understand it. I've considered
using it and given up on three separate occaisions, and I'm not the only
interpreter maintainer whose done that. Apart from that it also (AFAIK) has
the crippling restriction that it isn't compatible with resizing the display
window during play.
Neither is a sane choice for an intermediate API for use by other
interpreter cores, especially a (hypothetical) 32bit future virtual machine.
Bryan
Patrick Kellum
In article <slrn6bh6l...@zorg.hitchhiker.org>, Damien Neil was talking about:
>Hmm. Quote boxes are, unfortunately, the worst kind of feature: once
>upon a time, there was a system which implemented things a certain way.
>People took advantage of some of this system's idiosyncrasies. Now,
>everyone is required to duplicate those same idiosyncrasies, even in
>places where they make no sense at all.
How is printing standard text to the screen an idiosyncrasy? I have seen
it being done over primtive text terminals, this is not rocket science
here folks.
>Are you familiar with how quote boxes operate? To draw a quote box, one:
> a) Resizes the status window to cover the area of the screen where the
> quote box is to go.
> b) Draws the quote box _in the status window_(!).
> c) Resizes the status window back to its original size.
Why not just position the cursor to the required spot on the text wndow
and print? Too dificult?
>The assumption is that shrinking the status window is non-destructive.
>Unfortunately, this is not going to be true in any system written for
>a windowing environment, be it the Macintosh, MS-Windows, the X Windowing
Then don't use real wndows! This is what I'm getting at, the Z-Machine
was not ment to use a real windowng enviorment, it should not be hacked
into such an enviorment just to make it easer for lazy programmers.
To draw a status window, print to the top of the window in fixed-font. To
draw the text window, draw below that in proporitional font. When the
status window is refreshed it will overwrite any text that may have
scrolled over it.
>System, or even lowly curses (assuming you use the curses windowing
>features). Therefore, an interpreter writer is left with two choices:
>ignore all windowing system support, and just write everything by hand,
Whch s what was ntended in the frst place.
>or engage in nasty hacks involving status window size. (Xzip and (so
>I hear) MaxZip take the latter approach, which appears to work tolerably
>well.
I wouldn't call t workng since t seems to be causing so many problems.
>I have a strong suspicion that the Win95 interpreters are not using the
>Win95 text objects. (I cannot say for sure, never having used a Win95
What is so important about using text objects? If using this object
doesn't work then write a new one. That s what beng a programmer is
about, writing programs. It is becomng more and more common for people
who can only piece together a few objects to be called programmers. If
you don't know the code then don't program.
>interpreter.) The C64 interpreters clearly are not using any native
>text objects -- there aren't any. They also have a vastly simpler
And thank the Goddess for that. They seem to be more trouble then they
are worth.
>situation to deal with, as they use only a fixed width font. Introducing
>proportional fonts makes life vastly more interesting. (It also makes
>using native windowing system services vastly more appealing, to reduce
>the number of wheels that need to be reinvented.)
I use an Amiga, it uses a native wndowing system, it uses proportional
fonts, it allows quote boxes in the text window. Macs can't? Well, then
so sorry.
>I'm a bit unclear on what these hazards are. As far as I can tell, Glk
>offers a vastly more powerful output interface than the one currently
>supported by the Z-machine (with the exception of graphics, which would
>be easy enough to add into Glk's infrastructure). It seems that the only
Graphics would be required to appear in a seperate wndow. Damned ugly and
very sloppy.
>Z-machine feature that anyone is using which Glk does not offer support
>for is quote boxes overlayed onto a text window. Personally, I don't
And graphics in the same window.
>consider this much of a loss -- I can recall playing Trinity, and having
>quote boxes appear, covering text I hadn't read yet. Most annoying.
So, because you didn't like a feature then it should be removed?
>Furthermore, the manner in which a quote box should interact with a
>scrollback buffer is most unclear to me.
Either don't put the quote box text in the buffer (easy way) or put the
quote box text at the end of the latest text ignoring where it is printed
on the screen (harder way).
>In, perhaps, the same fashion Infocom did? The concept of a window is
>orthogonal to the concept of graphics. The Glk specification quite
>clearly indicates that a window can be, for example, "the top two lines
>of the screen".
Then, why are we now forbiden to do this? This is how Infocom handled it
on ther interpreters for orher platforms. This is exactally what the
Z-Machne was ment for. I wouldn't drive a car over a bridge and expect it
to fly, same thing.
>is pretty much spoken for), I can see no aspect of it which seems to
>cater to any Macintosh-specific limitations. Limitations of windowing
I can print different fonts in the same window, something it appears Macs
can't do. can locate the cursor to any point within that wndow and start
printing at that point, another thing Macs can't seem to do. Glk forbids
anything that a Mac can't do. I'm sure these things can be done on Macs,
but t appears Mac programmers can't be bothered to actually program.
>systems in general, perhaps -- but any such limitations apply equally
>to Windows, Java's AWT, X, and others just as much as to the Macintosh.
The windowing system I use allows all the features of the Z-Machne. I
should be allowed to continue using these features. If I write a game
that uses these features then I will expect the interpreters to deal with
t. The current system of /O on the Z-Machine s fine, it works great and
allows for some great effects. It actually requires an interpreter writer
to read the specfication but that should be expected.
Patrick Kellum
In article <VA.0000008...@butterfly.fsel.com>, Bryan Scattergood was talking about:
>deferring the 'shrink' until character input is another. In my case I plot
>the upper-window text over the flowed text in the lower window, keeping
>track of which character cells in the upper window are transparent (having
>never been printed.) It doesn't really matter which solution is used,
Why? Why not just move the current cursor position to the proper location
in the lower wndow and start printing? Oh yeah, I forgot Macs can't do
this simple task.
>because the fact the two windows use different fonts is enough to break your
>assumption that the screen-size tells you anything meaningful about the
>lower-window.
I've already mentioned how to get the screen wdth in characters usng
proporitional fons, I won't bother yet again.
>impossible on machines with small screens. (The Z-machine requires a minimum
>upper window size of 64 columns by 16 rows. Some of the platforms which
>currently have interpreters cannot meet that requirement, even using the
>smallest font available. The only reasonable way to fake it is to make the
>upper window larger than physical screen (which is larger than the lower
>window) and to pan around the upper window. That breaks your assumption
>again.)
Where are you getting ths 64 column limit? I've read the specification
and I can't find it. The Z-Machine runs fine on the Commodore 64 (a
machine that only has 40 columns) and I've been told t can run on the
Vic-20 (20 columns) lthough I haven't seen that yet.
Patrick Kellum
>block quotes can't be implemented quite as prettily as they are on some
>current platforms (they have to disappear when input happens.) That may be a
>shame, but as an interpreter maintainer I *can* tell you that the complexity
>they add to the display code is considerable. Zarf has taken the decision
>that the cost they add to porting GLK isn't worth the benefit.
Then Glk is flawed. Features shouldn't be removed just because a
programmer or operating system can't deal with them. They should be
removed for that system or programmer. I don't read Spanish, I will most
likely never learn Spanish. This does not mean I can tell everybody that
they can not release a game in Spanish. If you want to use real wndows
despite the fact that this is not how it should be done, then fine. But
we shouldn't be required to all start using real wndows.
>The Z-machine as-is provides two I/O models. The Z5 model is too
>restrictive, with no scope for graphics or multiple text windows. The Z6
>model is so complicated that I still don't understand it. I've considered
>using it and given up on three separate occaisions, and I'm not the only
>interpreter maintainer whose done that. Apart from that it also (AFAIK) has
>the crippling restriction that it isn't compatible with resizing the display
>window during play.
Frst, f you don't understand the V6 standard then don't use it. There,
sinple. Second, it does allow resizing the window, just wrte the new size
in to the header.
The V5 /O is fne, it does what t needs to do in an effecent maner. It's
interpreter authors who are makng it sloppy by using absured windowing
setups for ther interpreters.
V6 is wonderful, it allows interupts after each new line and other great
features. If you can't understand the features of V6 then so be it.
>Neither is a sane choice for an intermediate API for use by other
>interpreter cores, especially a (hypothetical) 32bit future virtual machine.
would rather see V6 screen system cleaned up a little for use in a future
Z-Machine, it has all the needed features for the future of Interactive
Fiction.
Patrick Kellum
Just one thought. What do we want? Why should we use the web as a
template for future IF? Do we really need to start droping well
established features just to make it easer for new programmers to port
something that should be done by experanced programmers anyway?
Personally, see no benifit in this proposed Glk standard, it appears to
be a standard for the sake of writing one. It doesn't properly support
the Z-Machine and will cause older games to display incorrectly on Glk
interpreters. It will basicly make a mess of IF, turning t into some
tacky HTML style monstrosity.
Jeff Hatch
Patrick Kellum wrote:
[snip]
> Personally, see no benifit in this proposed Glk standard, it appears to
> be a standard for the sake of writing one. It doesn't properly support
> the Z-Machine and will cause older games to display incorrectly on Glk
> interpreters. It will basicly make a mess of IF, turning t into some
> tacky HTML style monstrosity.
I don't agree with most of your criticisms of the Glk standard, or most
of your arguments in favor of the Z-machine standard. But regardless,
what difference does it make? I don't see how a new standard can hurt,
no matter how bad it is! If the Z-machine is better, Inform gamers will
continue to use a custom Z-machine interface. Even then, the Glk
standard might benefit other systems. Inform is arguably the best
currently available authoring system, but it's not the only system, and
many others don't support the Z-machine.
Minimum standards don't generally force good systems down to the least
common denominator. Instead, they raise the bad ones to a minimum level
and make things easier for users at all levels. When ANSI C became the
standard, did video game designers stop using graphics and start using
"printf" and "scanf" for all their interfacing needs?
Similarly, I don't think IF authors and gamers will be stupid enough to
use the Glk standard if it's not adequate for their needs.
-Rúmil
Andrew Plotkin
Patrick Kellum (pat...@syix.com) wrote:
> >Uh, but he isn't talking about any lowest common denominator: He's talking
> >about not allowing authors to do highly system-dependent stuff -- such as
> >specifying font names, or formatted-font-specific-colored styles etc.
> No, he wants to dis-allow authors from using features of the Z-Machine.
> This is NOT system-dependent.
I'm not talking about the Z-machine at all. I'm talking about future IF
systems, and current ones which are not well-ported (like Hugo.) (Or even
TADS. Howzabout a zero-effort Pilot port of TADS?)
> And he is talking lowest common denominator. If the Mac doesn't support a
> feature then it is not allowed. That is the basis of Glk as I read it.
You read... wrongly.
> >A porter is not programming anything -- he is porting a program from one
> >system to another. The whole point of the Glk specification is to make that
> >as easy as possible.
> Wrong! Have you ever ported something from one system to another? Unless
> it uses a simple StdIO interface (printf and such) then it does require
> massive programming.
I have a dream that this is not so. I have a dream that it can be made as
easy as StdIO porting is. And I think I've implemented most of my dream,
too.
Enough.
Andrew Plotkin
I want a serious romantic relationship with a nice girl.
I also want a circuit diagram for a set of chasing lights -- a small set,
five or six, preferably "fading" in and out (each one fading on as the
last one is going off, in turn around the circle.) The problem is that
these are AC-powered lights -- and in fact it's not standard house
current, but some high-frequency juice I haven't measured yet. Can anyone
provide a clue? Email only.
Oh, yeah, Glk.
> Personally, see no benifit in this proposed Glk standard, it appears to
> be a standard for the sake of writing one. It doesn't properly support
> the Z-Machine and will cause older games to display incorrectly on Glk
> interpreters. It will basicly make a mess of IF, turning t into some
> tacky HTML style monstrosity.
A Glk interpreter is not a Z-machine interpreter. In fact, the word
"interpreter" isn't even being used the same way in those two phrases.
You could write a Glk-based Z-machine(v5/8) interpreter. It would support
very nearly every Z-machine feature I know of, including color and quote
boxes (the latter done the way MaxZip does them.)
But this *is not* the sum total purpose of Glk, or even a major purpose.
I have quite a nice Glk-based AGT interpreter running now, on my Mac.
(Based on Agility.) It looks and plays like MaxZip and MaxTADS -- *not*
like the (crappy, terminal-window-style) Mac Agility I knocked off a few
months ago.
It still has wires hanging out the back, metaphorically, so I'm not
releasing it yet. But *this* is what Glk is for.
Rhodri James
In article <698q5n$4iu$1...@neko.syix.com>,
Patrick Kellum <pat...@syix.com> wrote:
> In article <34bf6906...@news.virgin.net>, Steve Waddicor was
> talking about:
> >No, an M is conventionally the widest character in a font. That's why
> >the unit for measuring widths in a font is an 'em'. The W is wider
> >than the O too.
> "0", not "O", i.e. Zero, not Ohhhh.
An "M" is conventionally wider than an "0" too. In fact an "O" is
generally wider than an "0". The point being?
--
Rhodri James *-* Wildebeeste herder to the masses
If you don't know who I work for, you can't misattribute my words to them
... Error: routine Lunchtime is purely virtual
Rhodri James
In article <69b9em$hdo$2...@neko.syix.com>,
Patrick Kellum <pat...@syix.com> wrote:
> In article <VA.0000008...@butterfly.fsel.com>, Bryan Scattergood
> was talking about:
> >deferring the 'shrink' until character input is another. In my case I
> >plot the upper-window text over the flowed text in the lower window,
> >keeping track of which character cells in the upper window are
> >transparent (having never been printed.) It doesn't really matter
> >which solution is used,
> Why? Why not just move the current cursor position to the proper
> location in the lower wndow and start printing? Oh yeah, I forgot Macs
> can't do this simple task.
Bryan isn't talking about Macs. Nor is he talking about something as
simple as "just printing" from an arbitrary pixel coordinate. Your
preconceived notions of what is going on at *any* level appear to be
getting in the way here.
> >because the fact the two windows use different fonts is enough to
> >break your assumption that the screen-size tells you anything
> >meaningful about the lower-window.
> I've already mentioned how to get the screen wdth in characters usng
> proporitional fons, I won't bother yet again.
Actually you said:
> Subtract the length of the text (divided by 2) from the width of the
> screen (in characters, divided by 2). To get the width of the screen in
> proporational fonts take the width of the "0" character and use that as
> the character width (standard practice).
I presume the second sentence is the (interestingly non-standard) method
of getting the "screen wdth". I hope you aren't intending to know these
values as an author?
PS: your method of quoting is outstandingly annoying. Please don't indent
so far, it makes requoting what you've quoted much more tedious than is
necessary.
--
Rhodri James *-* Wildebeeste herder to the masses
If you don't know who I work for, you can't misattribute my words to them
... Unfortunately we also have the stealth of elephants
Andrew Plotkin
Andrew Plotkin (erky...@netcom.com) wrote:
> You could write a Glk-based Z-machine(v5/8) interpreter. It would support
> very nearly every Z-machine feature I know of, including color and quote
> boxes (the latter done the way MaxZip does them.)
I'm sorry, I was getting overenthusiastic. It could not support the
@set_color opcode. It could request that particular styles have
particular colors, and it could do reverse text by requesting inverted
colors, but that's not the same thing.
Remember, of course, that it is not necessary to support Z-machine color
in order to be spec-compliant. The spec even includes a header bit you can
set to declare whether you support color or not. Remember?
Anyway:
> But this *is not* the sum total purpose of Glk, or even a major purpose.
--Z
Bryan Scattergood
On 11 Jan 1998 20:28:41 GMT, Patrick Kellum wrote:
> In article <VA.0000008...@butterfly.fsel.com>, Bryan Scattergood was talking
> about:
> >block quotes can't be implemented quite as prettily as they are on some
> >current platforms (they have to disappear when input happens.) That may be a
> >shame, but as an interpreter maintainer I *can* tell you that the complexity
> >they add to the display code is considerable. Zarf has taken the decision
> >that the cost they add to porting GLK isn't worth the benefit.
>
> Then Glk is flawed. Features shouldn't be removed just because a
> programmer or operating system can't deal with them. They should be
> removed for that system or programmer. I don't read Spanish, I will most
> likely never learn Spanish. This does not mean I can tell everybody that
> they can not release a game in Spanish. If you want to use real wndows
> despite the fact that this is not how it should be done, then fine. But
> we shouldn't be required to all start using real wndows.
GLK does *not* remove any features. It slightly restricts the ways in which that
one feature can be implemented in order to make porting GLK to a new platform an
order of magnitude easier.
> >The Z-machine as-is provides two I/O models. The Z5 model is too
> >restrictive, with no scope for graphics or multiple text windows. The Z6
> >model is so complicated that I still don't understand it. I've considered
> >using it and given up on three separate occaisions, and I'm not the only
> >interpreter maintainer whose done that. Apart from that it also (AFAIK) has
> >the crippling restriction that it isn't compatible with resizing the display
> >window during play.
>
> Frst, f you don't understand the V6 standard then don't use it. There,
> sinple. Second, it does allow resizing the window, just wrte the new size
> in to the header.
Uh huh. And what happens to the existing window contents when I resize it? How can
I rewrap the text when I need to call a piece of Z-code after each line-break and
that code may no longer expect to be called?
> The V5 /O is fne, it does what t needs to do in an effecent maner. It's
> interpreter authors who are makng it sloppy by using absured windowing
> setups for ther interpreters.
The 'absurd windowing setups' are sometimes the only way to get the Z5 model working
on a particular platform. Would you rather we hadn't bothered and left you with only
PC users?
> >Neither is a sane choice for an intermediate API for use by other
> >interpreter cores, especially a (hypothetical) 32bit future virtual machine.
>
> would rather see V6 screen system cleaned up a little for use in a future
> Z-Machine, it has all the needed features for the future of Interactive
> Fiction.
Fine. Away you go. Any idea what proportion of Z-machine platforms currently support Z6?
Bryan
Bryan Scattergood
On 11 Jan 1998 20:18:30 GMT, Patrick Kellum wrote:
> >deferring the 'shrink' until character input is another. In my case I plot
> >the upper-window text over the flowed text in the lower window, keeping
> >track of which character cells in the upper window are transparent (having
> >never been printed.) It doesn't really matter which solution is used,
>
> Why? Why not just move the current cursor position to the proper location
> in the lower wndow and start printing? Oh yeah, I forgot Macs can't do
> this simple task.
Because, as four people have already tried to explain, THE BLOCK QUOTES AREN'T IN
THE LOWER WINDOW. It looks like they are, but they get there by horrid hacks
which force interpreter authors to jump through hoops to support them.
And 'move the cursor and just start printing' isn't the way the screen is driven
in any modern GUI.
> >because the fact the two windows use different fonts is enough to break your
> >assumption that the screen-size tells you anything meaningful about the
> >lower-window.
>
> I've already mentioned how to get the screen wdth in characters usng
> proporitional fons, I won't bother yet again.
I know I can estimate the screen-size by using the width of a notional character.
If you actually read my message, I was trying to explain that interpreters can't
sensibly change the size entered in the header slots to anything other than the
maximum size of the upper window because (a) the game needs that information and
(b) there are no guarantees about when the game will try to read it. You can't
/give/ that guarantee because of the established base of Z-machine games already
out there.
If the lower window and the upper window are using substantially different fonts
(20pt Helvetica versus 8 point Courier) and the header slots always reflect the
size based on the upper window font, then your assumptions fall to pieces: the
header may tell you can fit 60 characters across, but the lower window will be
lucky to manage 30.
Bryan
Magnus Olsson
In article <erkyrathE...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
>I have quite a nice Glk-based AGT interpreter running now, on my Mac.
>(Based on Agility.) It looks and plays like MaxZip and MaxTADS -- *not*
>like the (crappy, terminal-window-style) Mac Agility I knocked off a few
>months ago.
Cool.
And the whole point of Glk is - if I understand it correctly - that
anybody wanting to port this interpreter to, say, Win95, wouldn't
have to rewrite the entire screen interface from scratch, provided there
already existed a Glk library for Win95. Correct?
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Not officially connected to LU or LTH.
Patrick Kellum
>one feature can be implemented in order to make porting GLK to a new platform an
>order of magnitude easier.
Sounds like removing features to me.
>Uh huh. And what happens to the existing window contents when I resize it? How can
>I rewrap the text when I need to call a piece of Z-code after each line-break and
>that code may no longer expect to be called?
Download the source to the Amiga port of Frotz and take a look. Although
I see what you mean about the line-interupt.
>The 'absurd windowing setups' are sometimes the only way to get the Z5 model working
>on a particular platform. Would you rather we hadn't bothered and left you with only
>PC users?
Macs can't use terminal style windows?
>Fine. Away you go. Any idea what proportion of Z-machine platforms currently support Z6?
Windows, Amga, perhaps DOS and Unix as well (anyone want to check?). I'm
almost sure the BeOs port of Frotz also supports V6. This leaves
Commodores (possable, not wrtten yet) and Macs (possable, not written
yet).
Patrick Kellum
In article <VA.0000008...@butterfly.fsel.com>, Bryan Scattergood was talking about:
>Because, as four people have already tried to explain, THE BLOCK QUOTES AREN'T IN
>THE LOWER WINDOW. It looks like they are, but they get there by horrid hacks
>which force interpreter authors to jump through hoops to support them.
They can be, I draw them by hand and don't use the box command. I draw
them in the text window, they look exactally like the Inform ones. I'm
not sure the assembler Inform uses but I'm sure it's the same.
[ note before anyone asks, I haven't used this is any released games yet ]
>And 'move the cursor and just start printing' isn't the way the screen is driven
>in any modern GUI.
Why not, can't you lay out text? Seems like something any real GUI should
be able to handle.
Patrick Kellum
In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:
>I'm sorry, I was getting overenthusiastic. It could not support the
>@set_color opcode. It could request that particular styles have
>particular colors, and it could do reverse text by requesting inverted
>colors, but that's not the same thing.
>
>Remember, of course, that it is not necessary to support Z-machine color
>in order to be spec-compliant. The spec even includes a header bit you can
>set to declare whether you support color or not. Remember?
Ok, you're correct here, but why not support colours?
Patrick Kellum
In article <480712a9...@wildebst.demon.co.uk>, Rhodri James was talking about:
>PS: your method of quoting is outstandingly annoying. Please don't indent
>so far, it makes requoting what you've quoted much more tedious than is
>necessary.
I indent one space, is this too much?
Patrick Kellum
In article <34B985...@hatch.net>, Jeff Hatch was talking about:
>what difference does it make? I don't see how a new standard can hurt,
"That's the nice thing about standards, there are so many of them." Damn
I love that :-)
>and make things easier for users at all levels. When ANSI C became the
>standard, did video game designers stop using graphics and start using
>"printf" and "scanf" for all their interfacing needs?
No, it appears they switched to text objects. Looks like a step down from
printf to me :-)
>Similarly, I don't think IF authors and gamers will be stupid enough to
>use the Glk standard if it's not adequate for their needs.
Ok, sounds fare to me. I see it being as popular as the save-file
standard and v6 packing standard (i.e. not very).
Patrick Kellum
In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:
>I want a serious romantic relationship with a nice girl.
Don't we all :-)
>A Glk interpreter is not a Z-machine interpreter. In fact, the word
>"interpreter" isn't even being used the same way in those two phrases.
You did mention you were planning on having it form the bases of future
Z-Machine releases.
Also, since it would form the basis for future GUI's for interpreters, it
seems appropiate to consider it at least part of an interpreter.
>like the (crappy, terminal-window-style) Mac Agility I knocked off a few
So Macs can handle simple text output? Then why all the seperate wndows?
Patrick Kellum
In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:
>I'm not talking about the Z-machine at all. I'm talking about future IF
Well, you did at one point.
>systems, and current ones which are not well-ported (like Hugo.) (Or even
>TADS. Howzabout a zero-effort Pilot port of TADS?)
How about a port of Frotz to Geos (Commodore version)? Now that would be
cool!
>I have a dream that this is not so. I have a dream that it can be made as
>easy as StdIO porting is. And I think I've implemented most of my dream,
>too.
As long as it doesn't involve colour :-) (kiddng, I'm just kidding :-)
>Enough.
I agree, I'll post no more on the subject after tonight, I'm getting tired
of it anyway. I have softened my stance against Glk slightly, although I
still think it could be improved.
Patrick Kellum
Ok, this is my last post on this subject. Another post in another thread
made me realize I am turnng into a real jerk. I blame my parents for it
(hey, why not), my parents and... the colour blue, yeah that's it, the
colour blue is to blame. Cabage! Yes, cabage is to blame for me being a
jerk, I always knew cabage would lead to my downfall! Uhm, I better shut
up now :-)
Sorry,
Gunther Schmidl
>I'm not talking about the Z-machine at all. I'm talking about future IF
>TADS. Howzabout a zero-effort Pilot port of TADS?)
Yay!
How about a freeware Frotz port to the Pilot? :-)
--
+------------------------+----------------------------------------------+
+ Gunther Schmidl + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 + except temptation" -- Oscar Wilde +
+ A-4040 LINZ +----------------------------------------------+
+ Tel: 0732 25 28 57 + http://gschmidl.home.ml.org - new & improved +
+------------------------+---+------------------------------------------+
+ sothoth (at) usa (dot) net + please remove the "xxx." before replying +
+----------------------------+------------------------------------------+
Mark J Musante
Patrick Kellum (pat...@syix.com) wrote:
> In article <34bf6906...@news.virgin.net>, Steve Waddicor was talking about:
> >If the string is "This" it adds the width of the T to the width of the
> >h to the width of the i ...
> This is not the same thing.
Right. You said that the convention was to add up with width of the "0"
characters. I was attempting to refute that by saying: in the two systems I
currently work in (PalmOS & Win95/NT), there is an *exact* string length
measuring function which adds up the width of the individual characters (as
Steve Waddicor pointed out).
Come to think of it, that function is also available in X. So there are
at least three systems which don't measure strings by adding "0"s up. Now,
I don't write code for Macs (I haven't since 1990, anyway), so I don't know
if that system calculates string length the way you suggest.
-=- Mark -=-
Paul David Doherty
In article <On3x$7kH9G...@upnetnews02.moswest.msn.net>,
Brock Kevin Nambo <newsm...@earthling.net> wrote:
>
>Similar to HTML; the actual web page doesn't ask you what you want it to
>look like, but you tell the browser, "show me what this page wants to look
>like" or "I don't care what the page wants to look like, I want it to look
>like this".. (ok, if you use lynx, you get less options. But Lynx's
>formatting makes sense in "True" HTML.)
>
>Uh, is that clear?
It's basically wishful thinking, since not only do the WWW pages tell
you nowadays how they should be looked at ("This page looks best using
IE 4.0 in a 640x400 window"), they even prevent you from viewing them
unless you're using the page author's favorite browser. This is probably
what Patrick Kellum calls the "perversion" of HTML, and I agree.
As for the Z-machine: We have a Standard. We have an interpreter
(Frotz) in various incarnations (DOS, Win95, Amiga) that is about
99% standard compliant. If an Inform game runs fine under a
standard-compliant interpreter like DOS Frotz but refuses to work
under non-standard-compliant interpreters like Andrew Plotkin's
MaxZIP (based on the outdated ZIP interpreter) or Bryan Scattergood's
ports of the outdated InfoTaskForce interpreter, this seems to be
Andrew's and Bryan's problem. Andrew's Glk proposal is his way of
fixing the bugs in his port: by declaring them to be features of a
new, "easier" standard.
-- Dave
J. Holder
Thus spake Patrick Kellum <pat...@syix.com>:
: >Fine. Away you go. Any idea what proportion of Z-machine platforms currently support Z6?
: Windows, Amga, perhaps DOS and Unix as well (anyone want to check?). I'm
: almost sure the BeOs port of Frotz also supports V6. This leaves
: Commodores (possable, not wrtten yet) and Macs (possable, not written
: yet).
UNIX Frotz can support a text-only V6 game, but their aren't any.
No one has yet written the necessary I/O code to put the V6 graphics
into a window on X. To be portable and to not require people to
have to install any special widget sets (recognizing that most UNIX
users outside of the Linux community are NOT sysadmins) will require
writing the thing in very low level X-calls (Xt or Xlib). Not fun.
(This doesn't mean that I'm not looking into it in my copious spare
time (ha)).
--
John Holder (jho...@frii.com) http://www.frii.com/~jholder/
Sr. Programmer Analyst, J.D.Edwards World Source Company, Denver, CO
http://www.jdedwards.com/
Stephen Granade
On 12 Jan 1998, Paul David Doherty wrote:
> As for the Z-machine: We have a Standard. We have an interpreter
> (Frotz) in various incarnations (DOS, Win95, Amiga) that is about
> 99% standard compliant. If an Inform game runs fine under a
> standard-compliant interpreter like DOS Frotz but refuses to work
> under non-standard-compliant interpreters like Andrew Plotkin's
> MaxZIP (based on the outdated ZIP interpreter) or Bryan Scattergood's
> ports of the outdated InfoTaskForce interpreter, this seems to be
> Andrew's and Bryan's problem. Andrew's Glk proposal is his way of
> fixing the bugs in his port: by declaring them to be features of a
> new, "easier" standard.
I don't get this at all from the Glk spec. As I read it, Glk is a clean
set of APIs which provides sufficient power for many IF systems (multiple
windows, a reasonable framework for the addition of graphics) while making
the task of porting a system easy. As such its power lies not in rewriting
Z-machine I/O (which is already ported to many systems) but in offering an
easy porting path for systems which are not as well ported (Hugo, AGT, and
any future systems).
C'mon, folks, he's not leading a torch-weilding mob of villagers anxious
to overthrow the Z-spec. He's not trying to "cover up" any bugs in his
port of the Z-machine. He's trying to make future development of IF
systems easier. It's been, what, two years and no Mac port of Hugo?
Porting isn't an easy task; anything which makes it easier is a boon to
newer or struggling development systems.
Andrew, am I on target?
Stephen
P.S. The Z-machine is not the evolutionary end of IF.
--
Stephen Granade | Interested in adventure games?
sgra...@phy.duke.edu | Check out
Duke University, Physics Dept | http://interactfiction.miningco.com
J. Holder
: >Uh, but he isn't talking about any lowest common denominator: He's talking
: >about not allowing authors to do highly system-dependent stuff -- such as
: >specifying font names, or formatted-font-specific-colored styles etc.
: No, he wants to dis-allow authors from using features of the Z-Machine.
: This is NOT system-dependent.
I'm afriad that after reading the spec, the only feature I see not implemented
is the (OPTIONAL) set_color support. Since the definition of optional is
"not required" then there is nothing in the Z spec and the Inform model
that Glk can't support. It may be supported a tiny bit differently in one
case, but it _is_ all supported. And besides, on all the disparate platforms
with proportional support, the differences between ports vary widely, but all
support the Z-machine model accurately.
: And he is talking lowest common denominator. If the Mac doesn't support a
: feature then it is not allowed. That is the basis of Glk as I read it.
<BZZZT> Wrong.
[major snippage of pointless arcade simulation]
: Acording to the author, he wants to incorporate Glk into Inform. That
: makes it an authoring system.
It appears you have completely misunderstood Glk. Glk is an I/O library
specification, not dissimilar to the Curses library. An interpreter
can choose to use it as an interface to the OS. The Glk has nothing
to do with Inform, other than some people may port the Glk I/O Library
between systems, and once that is done, porting any interpreter that
has Glk I/O calls (Not just Zmachine interpreters, but TADS, AGT, Hugo,
etc) from platform to platform where the Glk code has been written once
with be exceedingly easy. Now do you understand?
: This is already possable wthout Glk. Do you really belive that every
: system out there handles bold text in the same manner?
No, we don't, and that is why a given OS's Glk I/O Library implementation
will be a package unto itself.
: And the author is not allowed to say what colour the text should be.
: Currently this is allowed in all properly-written interpreters.
Again, Color support is optional. And my properly-written Jzip doesn't
support color in all cases. Would you like to know why? You probably
don't give a crap, but in UNIX and VMS, most terminal apps DO NOT SUPPORT
COLOR. And to be honest, even tho my 'terp can be compiled to output
ANSI color codes on UNIX, and I know where to get color supporting terminals
apps, I prefer to use the white-on blue xterms that I get to define - if
an author put too many ugly color into the game, I will either play it on
a mono interpreter, or not play it at all.
: >Something like HTML, really. Only more restrained in order to *clarify* the
: >situation for the author.
: This is my fear. I can just see it now "This game is for MaxZip. Go out
: and get a real interpreter.".
You will not see this. The MaxZip core is a Zmachine emulator, as all other
Z-code supporting interpreters are. What library the interpreter uses
when outputting the game info to the OS/Windowing System is the interpreter
writer's business.
Obviously, text formatting changes in Inform are not Andrew's to decide.
Graham is the guy who has the right, and no one is suggesting that anyone
else does. The support in Glk for such critters are at the I/O library
level. This mean that some future version of Z-code or some entirely new
game writing system would have the freedom to do so IF THE AUTHOR OF SAID
SYSTEM WANTED TO INCORPORATE IT. Ie, the Glk I/O Library would have
features above and beyond what the Z-Machine would use.
Nobody said that Glk would be ideal for V6, either.
Okay. Enough rant. I have the feeling that a) you don't get it b)you
won't get it and c)you don't care.
J. Holder
: quote box text at the end of the latest text ignoring where it is printed
: on the screen (harder way).
And ignoring the Zmachine spec, which says the text must be printed in
Window Zero. (Because AT THE Z-Machine assembly level, that is what the
opcides say to do.) It is easily conceivable that by ignoring this aspect of
the spec to support text boxes that you would break most status line
implementations. Or, you write your own routine to put text into the text
window as a "quote box" (heh), and expect it to look crappy on some
proportional-font platforms. Even, I'll wager, WinFrotz.
: The windowing system I use allows all the features of the Z-Machne. I
: should be allowed to continue using these features.
Okay, if you are writing graphic V6 adventures, don't use an interpreter
that supports the Glk I/O library if you don't like it.
: If I write a game
: that uses these features then I will expect the interpreters to deal with
: t.
You cannot expect an interpreter to use color. The spec tells you this flat
out. What is a Palm pilot interpreter author to do? "Damn, I won't port
to the Palm Pilot because it doesn't support color and Patrick would be pissed
that his poor game didn't have color. *sigh*" Grow up.
: The current system of /O on the Z-Machine s fine, it works great and
: allows for some great effects. It actually requires an interpreter writer
: to read the specfication but that should be expected.
Yes, the specification that says color is optional and IF authors shouldn't
expect it to be on any given system. You need to read it more carefully,
Patrick.
Magnus Olsson
In article <Pine.SUN.3.91.980112...@bigbang.phy.duke.edu>,
Stephen Granade <sgra...@phy.duke.edu> wrote:
>On 12 Jan 1998, Paul David Doherty wrote:
>
>> As for the Z-machine: We have a Standard. We have an interpreter
>> (Frotz) in various incarnations (DOS, Win95, Amiga) that is about
>> 99% standard compliant. If an Inform game runs fine under a
>> standard-compliant interpreter like DOS Frotz but refuses to work
>> under non-standard-compliant interpreters like Andrew Plotkin's
>> MaxZIP (based on the outdated ZIP interpreter) or Bryan Scattergood's
>> ports of the outdated InfoTaskForce interpreter, this seems to be
>> Andrew's and Bryan's problem. Andrew's Glk proposal is his way of
>> fixing the bugs in his port: by declaring them to be features of a
>> new, "easier" standard.
Pardon my French, but this is outright paranoia.
>I don't get this at all from the Glk spec.
Neither do I.
>As I read it, Glk is a clean
>set of APIs which provides sufficient power for many IF systems (multiple
>windows, a reasonable framework for the addition of graphics) while making
>the task of porting a system easy. As such its power lies not in rewriting
>Z-machine I/O (which is already ported to many systems) but in offering an
>easy porting path for systems which are not as well ported (Hugo, AGT, and
>any future systems).
>
>C'mon, folks, he's not leading a torch-weilding mob of villagers anxious
>to overthrow the Z-spec. He's not trying to "cover up" any bugs in his
>port of the Z-machine. He's trying to make future development of IF
>systems easier. It's been, what, two years and no Mac port of Hugo?
>Porting isn't an easy task; anything which makes it easier is a boon to
>newer or struggling development systems.
And I honestly can't see why this would make people so upset.
And even *if* Andrew were indeed leading a torch-wielding mob about to
overthrow the Z-spec, things wouldn't be so bad.
Stop to think about it: If Glk and the Z-machine don't mix, nobody
is going to force Stefan Jokisch to castrate Frotz in order to conform
to Glk. Andrew isn't *that* powerful.
Similarly, if a Glk Z interpretr turns out to be too castrated to play the
existing games in an acceptable way (aceptable to players, that is, not to
the itnerpreter writers), then people will continue to use the old
interpreters and shun the new ones.
It's as easy as that: nobody is forcing anybody to do anything.
J. Holder
Thus spake Paul David Doherty <h014...@joker.rz.hu-berlin.de>:
: As for the Z-machine: We have a Standard. We have an interpreter
: (Frotz) in various incarnations (DOS, Win95, Amiga) that is about
: 99% standard compliant. If an Inform game runs fine under a
: standard-compliant interpreter like DOS Frotz but refuses to work
: under non-standard-compliant interpreters like Andrew Plotkin's
: MaxZIP (based on the outdated ZIP interpreter) or Bryan Scattergood's
: ports of the outdated InfoTaskForce interpreter, this seems to be
: Andrew's and Bryan's problem.
It sounds like you don't believe it is possible for a Zip-based interpreter
to be Spec compliant. You are wrong. True, the Zip core has no compliant
V6 port. The changes to become compliant for Zip outside of V6 are not
that big. And I believe that Andrew's MaxZip is probably Spec 0.2 compliant
at least. Some of the "suggested behaviors" that the Zip core doesn't follow
are the strict, game ended things that cause Frotz to end. Andrew has
also added stuff to MaxZip that will tell authors when they perform
"crashable" errors, but still allow the game to continue in some cases.
Anyhow. Enough from me on this. Andrew?
: Andrew's Glk proposal is his way of
: fixing the bugs in his port: by declaring them to be features of a
: new, "easier" standard.
I have no reason at all to believe this is the case.
Andrew Plotkin
> > Andrew's Glk proposal is his way of
> > fixing the bugs in his [ZIP] port: by declaring them to be features
> > of a new, "easier" standard.
> I don't get this at all from the Glk spec. As I read it, Glk is a clean
> set of APIs which provides sufficient power for many IF systems (multiple
> windows, a reasonable framework for the addition of graphics) while making
> the task of porting a system easy. As such its power lies not in rewriting
> Z-machine I/O (which is already ported to many systems) but in offering an
> easy porting path for systems which are not as well ported (Hugo, AGT, and
> any future systems).
> Andrew, am I on target?
Yes. Thank you.
> C'mon, folks, he's not leading a torch-weilding mob of villagers anxious
> to overthrow the Z-spec.
Secretly, of course, I *have* always wanted to lead a torch-wielding mob
of villagers. Haven't we all? But there are lots of targets on the list
above the Z-spec.
Andrew Plotkin
Patrick Kellum (pat...@syix.com) wrote:
> In article <erkyrathE...@netcom.com>, Andrew Plotkin was talking about:
> >A Glk interpreter is not a Z-machine interpreter. In fact, the word
> >"interpreter" isn't even being used the same way in those two phrases.
> You did mention you were planning on having it form the bases of future
> Z-Machine releases.
I mentioned that it is a *possible* basis for future Z-machine
*versions*. Or -- more accurate -- a future Z-machine successor. There
are other things that can be fixed besides the I/O system. A 32-bit
memory space is top of the list.
But... one thing at a time, yes?
> Also, since it would form the basis for future GUI's for interpreters, it
> seems appropiate to consider it at least part of an interpreter.
> >like the (crappy, terminal-window-style) Mac Agility I knocked off a few
> So Macs can handle simple text output? Then why all the seperate wndows?
The (crappy, terminal-window-style) I/O library I used for Mac Agility is
called SIOUX. It's adequate for quick tools, from source code that uses
stdin/stdout and printf. It is *not* adequate for a serious Mac program.
It's not even an adequate terminal emulator. It doesn't support cursor
movement -- you can only print at the end. The Mac Agility cheap port
doesn't have a status line. The Glk port does.
(There *are* adequate terminal emulator libraries for the Mac. I'm
typing this in a VT320 emulator window. But I only put up with it because
of the job at hand: interacting with a curses.h program running on the
Unix machines at Netcom, over a modem link. From a Mac point of view,
this interface is *hopeless*. You can't even click to move the insertion
mark! You can't *cut*! It doesn't support proprtional fonts!)
By the way, it sounds like you're misinterpreting what I mean by
"separate windows".
Julian Arnold
> I'm not talking about the Z-machine at all. I'm talking about future IF
> systems, and current ones which are not well-ported (like Hugo.) (Or even
> TADS. Howzabout a zero-effort Pilot port of TADS?)
See, from the other posts I thought you *were* being Z-machine-centric.
I'm glad you've said that you aren't.
Jools, who still hasn't read the Glk spec
--
"For small erections may be finished by their first architects; grand
ones, true ones, ever leave the copestone to posterity. God keep me from
ever completing anything." -- Herman Melville, "Moby Dick"
Paul David Doherty
In article <69dhvt$fo5$2...@europa.frii.com>,
J. Holder <jho...@io.frii.com> wrote:
>Thus spake Paul David Doherty <h014...@joker.rz.hu-berlin.de>:
>: As for the Z-machine: We have a Standard. We have an interpreter
>: (Frotz) in various incarnations (DOS, Win95, Amiga) that is about
>: 99% standard compliant. If an Inform game runs fine under a
>: standard-compliant interpreter like DOS Frotz but refuses to work
>: under non-standard-compliant interpreters like Andrew Plotkin's
>: MaxZIP (based on the outdated ZIP interpreter) or Bryan Scattergood's
>: ports of the outdated InfoTaskForce interpreter, this seems to be
>: Andrew's and Bryan's problem.
>
>It sounds like you don't believe it is possible for a Zip-based interpreter
>to be Spec compliant. You are wrong. True, the Zip core has no compliant
>V6 port. The changes to become compliant for Zip outside of V6 are not
>that big. And I believe that Andrew's MaxZip is probably Spec 0.2 compliant
>at least.
And I believe Andrew has proudly stated on several occasions that MaxZIP
is not Spec 0.x or 1.x compliant.
(Besides, I'm not bashing the Glk proposal, which I admit I haven't
read yet. It just seems odd that Andrew can't add Spec compliancy
to MaxZIP - for a variety of reasons ranging from "I don't feel like
it" to "I don't want to" [1] - but has no problems proposing and
implementing his own standards whenever it strikes his fancy.)
-- Dave
[1] quoting from memory, obviously, but I can dig up dozens of real
quotes if required
Bryan Scattergood
On 11 Jan 1998 20:18:30 GMT, Patrick Kellum wrote:
> >upper window size of 64 columns by 16 rows. Some of the platforms which
> >currently have interpreters cannot meet that requirement, even using the
> >smallest font available. The only reasonable way to fake it is to make the
> >upper window larger than physical screen (which is larger than the lower
> >window) and to pan around the upper window. That breaks your assumption
> >again.)
>
> Where are you getting ths 64 column limit? I've read the specification
> and I can't find it.
Sorry. I was off by a few, but section 8.4 in ZSpec 1.0 has
"The screen should ideally be at least 60 characters wide by 14 lines deep"
I must have been thinking of the TRS-80 screen size.
> The Z-Machine runs fine on the Commodore 64 (a machine that only has 40
> columns) and I've been told t can run on the Vic-20 (20 columns) lthough I
> haven't seen that yet.
Most games cope fine. However, a few games break or refuse to start if the size
is less than 80x25. Some (including Bureaucracy) stop working around 60 columns.
Often it is only the online hints system which breaks (and sometimes the box
quotes hang off the edges of the screen), but it still annoys users of machines
with small-screens.
BTW: A Vic-20 interpreter? On a 22x23 screen, 1MHz 6502 and a memory system that
maxes out around 28K? (Okay, 31K if you push it, but more practically 20K.)
Bryan
Den of Iniquity
On Mon, 12 Jan 1998, Andrew Plotkin wrote:
>> Just one thought. What do we want?
>
>I want a serious romantic relationship with a nice girl.
Ooh, that's a toughy. Have you tried looking through the Doom source
code... no, hang on, that's a dead-end for sure. *
Or how about shining that pen-laser through a diffuse... no, that's no
good either.
Funny thing is, those silly romances often get things right - serious
romantic relationships seem to turn up when you're _not_ looking for them.
Or is that just the Thing That Your Aunt Gave You That You Don't Know What
It Does?
Anybody got an old lamp? New lamps for old...
--
Den
* Why did ID have to release that? Now we've got Amiga Doom and Bang!
Where the hell did that weekend go?
Ethan Dicks
In article <VA.0000008...@butterfly.fsel.com>,
Bryan Scattergood <1O431...@compuserve.com> wrote:
>On 11 Jan 1998 20:18:30 GMT, Patrick Kellum wrote:
>> The Z-Machine runs fine on the Commodore 64 (a machine that only has 40
>> columns) and I've been told t can run on the Vic-20 (20 columns) lthough I
>> haven't seen that yet.
I haven't released it, yet.
>BTW: A Vic-20 interpreter? On a 22x23 screen, 1MHz 6502 and a memory
>system that
>maxes out around 28K? (Okay, 31K if you push it, but more practically 20K.)
I've decompiled the C-64 Z-machine from Infocom and modified it so that it
works fine on an emulated VIC-20 (xvic) with RAM from $0000-$7FFF (data) and
RAM from $A000-$BFFF (interpreter). It is not currently ROMable, but it could
be made so with little effort. I changed the status line routines to not print
"Time:" and "Score:", but occasionally, the score overwrites the room name.
It isn't pretty, but it does run. I'm waiting for a response from Activision
about if/how I can redistribute it.
Anyway, the VIC version wasn't my goal... I've got the same code nearly working
on the PET. (32K, 80-column, BASIC 4.0) I found one bug last week (double
use of a zero-page address) and there's at least one more to find, but it
mostly works.
-ethan
--
Ethan Dicks http://www.infinet.com/~erd/
(dicks) at (math) . (ohio-state) . (edu) sellto: postmaster@[127.0.0.1]
harvestbot fodder: pres...@whitehouse.gov fcc...@fcc.gov root@[127.0.0.1]
Jason C Penney
J. Holder (jho...@io.frii.com) wrote:
: Thus spake Patrick Kellum <pat...@syix.com>:
: : >Fine. Away you go. Any idea what proportion of Z-machine platforms currently support Z6?
: : Windows, Amga, perhaps DOS and Unix as well (anyone want to check?). I'm
: : almost sure the BeOs port of Frotz also supports V6. This leaves
: : Commodores (possable, not wrtten yet) and Macs (possable, not written
: : yet).
: UNIX Frotz can support a text-only V6 game, but their aren't any.
But... But... YES THERE ARE!!!! Well, ok, yes there is one. It's been
announced multiple times, and I've gotten emails from people who could
run it in UNIX Frotz. Ok, so it was Release 1, and no one seems to
want to test Release 3 to see if I fixed a problem that only showed up
in UNIX Frotz, but it does exist.
<ftp://ftp.gmd.de/if-archive/games/infocom/advent.z6>
Later,
Jay
who wonders if anyone can see him, or if its just John :(
----
Jason C Penney (jpe...@cs.uml.edu) Xarton Dragon -=<UDIC>=-
<http://www.cs.uml.edu/~jpenney/>
"The trouble with computers of course, is that they're very
sophisticated idiots." -- The Doctor
J. Holder
Thus spake Jason C Penney <jpe...@cs.uml.edu>:
: J. Holder (jho...@io.frii.com) wrote:
: : Thus spake Patrick Kellum <pat...@syix.com>:
: : : >Fine. Away you go. Any idea what proportion of Z-machine platforms currently support Z6?
: : : Windows, Amga, perhaps DOS and Unix as well (anyone want to check?). I'm
: : : almost sure the BeOs port of Frotz also supports V6. This leaves
: : : Commodores (possable, not wrtten yet) and Macs (possable, not written
: : : yet).
: : UNIX Frotz can support a text-only V6 game, but their aren't any.
: But... But... YES THERE ARE!!!! Well, ok, yes there is one. It's been
: announced multiple times, and I've gotten emails from people who could
: run it in UNIX Frotz. Ok, so it was Release 1, and no one seems to
: want to test Release 3 to see if I fixed a problem that only showed up
: in UNIX Frotz, but it does exist.
: <ftp://ftp.gmd.de/if-archive/games/infocom/advent.z6>
: Later,
: Jay
: who wonders if anyone can see him, or if its just John :(
AHHH! I'm sorry! I've negelected this effort. Sorry, Jay.
And someday I might actually get around to starting that code testing
of V6 lib that you've been sweating over, too... (guilty look)
Patrick Kellum
In article <69dq90$nl7$1...@mathserv.mps.ohio-state.edu>, Ethan Dicks was talking about:
>I haven't released it, yet.
That's why I didn't mention your name. Sorry if I steped out of line
here.
Andrew Plotkin
Paul David Doherty (h014...@joker.rz.hu-berlin.de) wrote:
> >And I believe that Andrew's MaxZip is probably Spec 0.2 compliant
> >at least.
> And I believe Andrew has proudly stated on several occasions that MaxZIP
> is not Spec 0.x or 1.x compliant.
I think "gleefully" is more accurate than "proudly".
> (Besides, I'm not bashing the Glk proposal, which I admit I haven't
> read yet. It just seems odd that Andrew can't add Spec compliancy
> to MaxZIP - for a variety of reasons ranging from "I don't feel like
> it" to "I don't want to" but
I think this is a misrepresentation. I have not been able to *guarantee*
Spec compliancy. I think I have been as diligent as anybody in responding
to and dealing with actual, reported problems in my interpreters.
For any given issue which I have been made aware of, I have either (1)
made MaxZip compliant, (2) decided that I could not do so without
compromising some important aspect of the interface, or (3) decided it was
not important enough to fix soon.
(To my knowledge, group (2) is all issues that result from my decision
that the player can resize the story window during play. In group (3), I
can think of two things: you can't input a line of text in the status
window (although you can input a key), and you can't nest stream-3
print-to-memory operations.)
(Group (3) used to also include a total failure to set the header bits
correctly. That *was* unacceptable, and it has been fixed, and I
apologize for the fact that it took until version 1.6.)
Even if groups (2) and (3) were empty, I would still be very leery of
*claiming* that it was Z-spec compliant. And honestly I think that other
interpreter porters and supporters are in the same boat. We can all of us
only fix the problem we know about. I may be, as I've said, just
constitutionally paranoid about what I *don't* know about.
> has no problems proposing and
> implementing his own standards whenever it strikes his fancy.)
This is of course true. Standards are fun!
It is not really relevant, but I can brag anyway, that I can probably fix
the status-window-input problem soon. I didn't want a similar flaw in my
Mac Glk library, so I wrote a better status-window object from scratch,
which *does* allow line input. I should be able to transplant that code
back into MaxZip. Rag not upon what I choose to implement. :-)
Bruce Stephens
Bryan Scattergood <1O431...@compuserve.com> writes:
> No. No. No. You are reading guarantees into the standard which (IMHO) just
> aren't there. Let me try and explain how I understand the screen model, and
> how I ended up there.
Bryan is, of course right. It's dead easy to come up with a better
system of doing I/O (approximately within the Z-machine framework),
which will allow proportional fonts, dynamic resizing, etc. Such a
thing would be cool, but would almost certainly fail on many old
games.
There's lots of legacy code out there, and one of the most important
features of a Z-code interpreter is that it be able to run a large
proportion of the classic Infocom games. The way of handling text
that's used in interpreters (fixed-sized font for the upper window,
possibly proportional text for the lower (main) window, and some kind
of hack for when the upper window gets resized) seems to work fine.
Bryan's Psion interpreter works amazingly well, for example.
Sticking a standard I/O layer between interpreters and their
interfaces also seems a superb idea.
Adam J. Thornton
In article <Pine.SGI.3.95L.98011...@ebor.york.ac.uk>,
Den of Iniquity <dms...@york.ac.uk> wrote:
>On Mon, 12 Jan 1998, Andrew Plotkin wrote:
>>> Just one thought. What do we want?
>>I want a serious romantic relationship with a nice girl.
>romantic relationships seem to turn up when you're _not_ looking for them.
>Or is that just the Thing That Your Aunt Gave You That You Don't Know What
>It Does?
That's only a Serious Romantic Relationship in the states of West Virginia,
Alabama, and Arkansas.
Oh, if only this post would propagate. But it won't. And I'm too lazy to
post it through DejaNews.
Adam
--
ad...@princeton.edu Cynical and drunk and boring someone in some dark cafe
Geoff Bailey
In article <erkyrathE...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
> This brings up a sticky problem -- what happens if you change a style
> hint after some text has already been printed? Honestly, I may make this
> illegal or let the results be undefined. (I want to allow interpreters to
> use very simple print-and-forget I/O. That is, nothing in the Glk spec
> forces interpreters to be able to redraw or reformat their windows.)
Is this really a problem? They are only hints, after all, so the Glk code
is free to handle them as it wishes. This may include such behaviour as
ignoring all hints, ignoring all but the first set of hints, or trying to
do something sensible if the hints change.
Cheers,
Geoff (probably missing the point as usual).
-------------------------------------------------------------------------------
Geoff Bailey (Fred the Wonder Worm) | Programmer by trade --
ft...@cs.su.oz.au | Gameplayer by vocation.
-------------------------------------------------------------------------------
Matthew T. Russotto
In article <fake-mail-120...@van-52-1037.direct.ca>,
Neil K. <fake...@anti-spam.address> wrote:
}pat...@syix.com (Patrick Kellum) wrote:
}
}> Macs can't use terminal style windows?
}
} Of course they can.
}
} Thank God they usually don't, except when emulating terminals.
Heh heh. The console routines in Zip Infinity all start with "ase" --
this stands for "Asynchronous terminal Screen Emulator".
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Bryan Scattergood
On 12 Jan 1998 16:53:35 +0100, Paul David Doherty wrote:
> As for the Z-machine: We have a Standard. We have an interpreter
> (Frotz) in various incarnations (DOS, Win95, Amiga) that is about
> 99% standard compliant. If an Inform game runs fine under a
> standard-compliant interpreter like DOS Frotz but refuses to work
> under non-standard-compliant interpreters like Andrew Plotkin's
> MaxZIP (based on the outdated ZIP interpreter) or Bryan Scattergood's
> ports of the outdated InfoTaskForce interpreter, this seems to be
> Andrew's and Bryan's problem.
Just a minute. You are trying to claim that if a game works on a compliant
interpreter but has problems on a non-compliant one the problem *has* to
be with the non-compliant interpreter. That doesn't follow.
Yeah, if a game fails under my ITF-derived interpreter because the
interpreter deviates from the standard, then I have a problem. However, a
game could also fail because it relies on features of a particular
interpreter which are not guaranteed by the standard.
Gaps in the standard are not necessarily problems with the standard. A
more rigourous standard could make life easier for game authors, but it
might also remove some of the options available to those porting
interpreters. What a standard leaves unspecified is at least as important
as what it does specify.
A particular interpreter has to resolve the unspecified areas in the
standard in one particular way (it is a real, concrete program.)
Compliance with the standard doesn't mean that every other interpreter has
to make the same choices in the unspecified areas. Without diversity in
the available interpreters, game authors will come to rely on features
which are not guaranteed, and that will make the task of future
interpreter authors harder than it should be.
(My day-job may be showing through. This distinction between an abstract
standard-with-ambiguities and concrete implementations is one of the
reasons we have formal specification languages as well as more traditional
programming languages.)
> Andrew's Glk proposal is his way of fixing the bugs in his port: by
> declaring them to be features of a new, "easier" standard.
That simply isn't true. GLK defines a screen model. Fitting the Z5 screen
model to that is (IMHO) possible without breaking compliance. I might be
persuaded that Patrick's tricks for centreing text in the lower window
are/should-be guaranteed by the standard, but I think the Z-machine list
is probably a better place for that discussion.
Bryan
Bryan Scattergood
On 12 Jan 1998 19:17:52 GMT, Ethan Dicks wrote:
> In article <VA.0000008...@butterfly.fsel.com>,
> Bryan Scattergood <1O431...@compuserve.com> wrote:
> >On 11 Jan 1998 20:18:30 GMT, Patrick Kellum wrote:
> >> The Z-Machine runs fine on the Commodore 64 (a machine that only has 40
> >> columns) and I've been told t can run on the Vic-20 (20 columns) lthough I
> >> haven't seen that yet.
>
> >BTW: A Vic-20 interpreter? On a 22x23 screen, 1MHz 6502 and a memory
> >system that
> >maxes out around 28K? (Okay, 31K if you push it, but more practically 20K.)
>
> I've decompiled the C-64 Z-machine from Infocom and modified it so that it
> works fine on an emulated VIC-20 (xvic) with RAM from $0000-$7FFF (data) and
> RAM from $A000-$BFFF (interpreter). It is not currently ROMable, but it could
> be made so with little effort. I changed the status line routines to not print
> "Time:" and "Score:", but occasionally, the score overwrites the room name.
Hmm. How are you coping with the fact that the video memory has to sit in the
$1000-$1FFF window which is partway through your nice 32K workspace? I'm trying
to remember if it was ever possible to configure a VIC so that your interpreter
could run. I remember some sort of three-cartridge adapter and that might have
had a rom socket on it as well. Or combine a ROM cartridge with a 3K and (rare)
24K rampack.
All academic anyway. The VIC is in an attic 300 miles away, and the tape-deck no
longer works.
> Anyway, the VIC version wasn't my goal... I've got the same code nearly working
> on the PET. (32K, 80-column, BASIC 4.0) I found one bug last week (double
> use of a zero-page address) and there's at least one more to find, but it
> mostly works.
Best of luck. Z8 support next? :-)
Bryan
Bryan Scattergood
On 12 Jan 1998 10:02:27 GMT, Patrick Kellum wrote:
> >Because, as four people have already tried to explain, THE BLOCK QUOTES AREN'T IN
> >THE LOWER WINDOW. It looks like they are, but they get there by horrid hacks
> >which force interpreter authors to jump through hoops to support them.
>
> They can be, I draw them by hand and don't use the box command. I draw
> them in the text window, they look exactally like the Inform ones. I'm
> not sure the assembler Inform uses but I'm sure it's the same.
I'm fairly sure Inform uses the print_table opcode which almost certainly only works
in the upper window. In any case, upper window block quotes are a nuisance and as
I've already explained I'm not sure your technique for centreing on the lower window
is guaranteed to work.
Bryan
Patrick Kellum
In article <VA.0000008...@butterfly.fsel.com>, Bryan Scattergood was talking about:
>are/should-be guaranteed by the standard, but I think the Z-machine list
>is probably a better place for that discussion.
Is the list still around? I've tried subscribing but the notice I recived
said the list was closed.
If it still exists, I would love to re-subscribe.
Patrick
[ "i" key is messed up, please ignore any errors. ]
Stu042
>On Mon, 12 Jan 1998, Andrew Plotkin wrote:
>
>>> Just one thought. What do we want?
>>
>>I want a serious romantic relationship with a nice girl.
>
>Ooh, that's a toughy. Have you tried looking through the Doom source
>code... no, hang on, that's a dead-end for sure. *
<Snip>
>* Why did ID have to release that? Now we've got Amiga Doom and Bang!
>Where the hell did that weekend go?
Just wait until Amiga Quake is out.. ;)
Stuart
Aquarius
Bryan Scattergood <1O431...@compuserve.com> wrote:
> (My day-job may be showing through. This distinction between an abstract
> standard-with-ambiguities and concrete implementations is one of the
> reasons we have formal specification languages as well as more traditional
> programming languages.)
There's a certain irony to a Z-machine spec in Z. :-)
Aquarius
--
------------------------------------------------------------------------
aqua...@cryogen.com | http://www.cryogen.com/aquarius/ | Running on Mac
I do believe in God. And the only thing that scares me is Keyser Sosek
------------------------------------------------------------------------
Jeremy A.Smith (not affiliated with Rancid the Elf)
Andrew Plotkin <erky...@netcom.com> wrote in article
<erkyrathE...@netcom.com>...
> I have a dream that this is not so. I have a dream that it can be made as
> easy as StdIO porting is. And I think I've implemented most of my dream,
> too.
>
> Enough.
I think this is an excellent idea. Stuff like this is what is missing in C,
and Java is too slow.
Besides, as for Patrick's comments, there is a Z-machine interpreter for
every machine in existence, just about, which will handle the games. These
already exist. But a Level9 interpreter doesn't exist for the Psion (would
be easy with GLK, I assume), which would be great, neither does a TADS
interpreter (I think), and so on.
So, good luck with your project. I'd help out with programming, but my
programming in C is a mess, to say the least.
--
Jeremy A.Smith
To reply by Email, change the 'z' in lwtcdz to i
Merry Tremble and a Crummy New Yeeeeaaaaaahhh!!
Advent Calendar:Finished
Articles:24 per day
http://www.homeusers.prestel.co.uk/lwtcdi/all/
Bryan Scattergood
On Wed, 14 Jan 1998 23:20:47 +0000, Aquarius wrote:
> Bryan Scattergood <1O431...@compuserve.com> wrote:
> > (My day-job may be showing through. This distinction between an abstract
> > standard-with-ambiguities and concrete implementations is one of the
> > reasons we have formal specification languages as well as more traditional
> > programming languages.)
>
> There's a certain irony to a Z-machine spec in Z. :-)
Well, *I'd* find it useful, and it is an appealing notion, but I also have a
pretty good idea just how much work would be involved. I've seen Z
descriptions of early 8 bit microprocessors and the Z-machine is significantly
more complex than any of those.
Besides, my Z is a little rusty :-( Been doing other things.
Bryan