Opinion: Are the new Z-Machines *TOO* fast?

6 views
Skip to first unread message

csha...@woh.rr.com

unread,
Oct 20, 2001, 1:50:09 PM10/20/01
to
All,

A few weeks ago I had the pleasure of playing (well, messing around
with, anyway) Frobnitz on a Palm M505 system. And it seemed to me, that due to
the limited processor and text scrolling speed of the palm device, the old
infocom games regained a lot of their charm.

Actually, what happened was the fooling around with the game
reignited my intrest in the old games, so I installed a copy of frotz on my
linux box, and loaded up my old favorite Zork II.

The last time I played Zork II was on an NCR Decision Mate V with
two floppy's. On that system, there just seemed to be something magical
about going into a new room for the first time, and having to wait the 2 or
3 seconds it took to pull the room description off the drive. I also
remember the feeling of accomplishment at solving a puzzle for the first
time and knowing that SOMETHING NEW was about to happen because you could
hear and see the floppy drive going to work.

It seems as though that feeling has been lost a little bit with the
new Z-Machine interpreters. They're so darn fast that solving a puzzle, or
entering a room you just left is handled with the same result. A belch of
text that suddenly pops up on the screen so fast you hardly have time to
notice that the screen has even scrolled at all.

Now, granted, the designers of the infocom games would probably have
been elated over the speed at which their games run now, but it just seems
to me that a little of the soul has been lost.

As the old saying goes, "the devil's in the details", even todays
blackjack and other card-games, try to "smoothly" animate the dealing of
cards, even though it's just as easy to make the new cards suddenly appear in
your hand. It's almost as if the wetware in our heads "needs" details like
blinking cards, or smooth animation in order to processes the fact that "Oh,
yeah, *THIS* item has moved from here to there"

As an avid player of gnuChess, I find it MUCH easier to interpret
moves when the chess-men blink, first, or slide into place as opposed to
simply popping into their new positions.

So, I'm wondering if anyone else has felt something similar in the
new z-machines? And I propose a question to the Z-Machine developers...
Would it be very difficult to put a few usleep(); calls into the text print
routines that slow down the display just a little bit?

I'm certainly not advocating a return to a 300 baud text-printing
mechanism, but just a slight slowing down, so that we can actually see the
screen scroll as apposed to simply advancing 5-10 lines of text instantly?

I'm not the worlds greatest programmer, but I did try playing with
the source-code to frotz a little bit, and I stuck in some usleep calls
between the buffer_flush() and new_line() calls, but unfortunatly the
ncurses or maybe xterm's output algorithms were working against me, and what
I would up with was just a total-pause after hitting return, and then a
jump-scroll of the whole text. I couldn't get the output text to pop-up
line by line.

Provided that there's a way around ncurses or terminfo's or
whatever, buffering the screen output all-at-once, it shouldn't be too hard
to put in a command line option for somekind of "delay" between output
lines.

But, then maybe I'm the only one who feels this way.

Oh, yeah... turning off jump-scroll in my xterm doesn't have any
real effect. On a genuine VT terminal, I could always enable
smooth-scroll... but even that *really* isn't the same thing...

Comments anyone?


Kevin Forchione

unread,
Oct 20, 2001, 2:48:20 PM10/20/01
to
<csha...@woh.rr.com> wrote in message
news:lPiA7.5953$Fx6.2...@typhoon.columbus.rr.com...
<snip>
> Comments anyone?

Very interesting observations. Certainly a 2-3 second response time would
allow for a tremendous amount of background processing ... newer libraries
could be built that did far more complicated simulationist computations.

But when WorldClass first came out there were negative comments about the
"slowness" of the system. Most people appear to *want* an unnoticeable
response time between hitting the enter key and having text displayed. Many
would argue that the "grinding" of the drive while loading a large chunk of
new data gave away some clues to the importance of the action.

Doesn't inform offer some kind of delay in the programming language itself?
Couldn't you alter LibraryMessages to feed you the data more slowly?

--Kevin


Matthew Russotto

unread,
Oct 20, 2001, 2:57:35 PM10/20/01
to
In article <lPiA7.5953$Fx6.2...@typhoon.columbus.rr.com>,
<csha...@woh.rr.com> wrote:
>
> Comments anyone?

Yeah, I swear I've read this article already, a long time ago.
--
Matthew T. Russotto russ...@pond.com
=====
Get Caught Reading, Go To Jail!
A message from the Association of American Publishers
Free Dmitry Sklyarov! DMCA delenda est!
http://www.freedmitry.org

csha...@woh.rr.com

unread,
Oct 20, 2001, 4:05:59 PM10/20/01
to
Kevin Forchione <ke...@lysseus.com> wrote:
> <csha...@woh.rr.com> wrote in message
> news:lPiA7.5953$Fx6.2...@typhoon.columbus.rr.com...
> <snip>
>> Comments anyone?

> Very interesting observations. Certainly a 2-3 second response time would
> allow for a tremendous amount of background processing ... newer libraries
> could be built that did far more complicated simulationist computations.

Well, 2-3 seconds might be too long, but even 1/2 a second before processing
a command, and maybe 1/10th-1/20th of a second delay on displaying lines of
text would be nice.

> But when WorldClass first came out there were negative comments about the
> "slowness" of the system. Most people appear to *want* an unnoticeable
> response time between hitting the enter key and having text displayed. Many
> would argue that the "grinding" of the drive while loading a large chunk of
> new data gave away some clues to the importance of the action.

True, slow is slow... but I'm think more along the lines "adding abiance" by
proposing we recreate the "ripple" effect as text used to scroll up the
screen. The zmachines today are SO fast that an entire page of text just
POPS into existance... we've lost the feel of seeing the text scroll up the
screen. One minute you're typing in your command and before your finger has
released the return key the entire page has been replaced with a full-screen
of new text that suddenly BLINKED into existance.

My point is, that I find this a little jarring. I'm delighted to say the
the frobnitz interpreter that runs on the PALM devices is slow enough (or
the palm is slow enough) to return that old feeling of actually seeing the
text lines scroll up the screen. I like it. It just "feels" like the old
infocom games did. :)

> Doesn't inform offer some kind of delay in the programming language itself?
> Couldn't you alter LibraryMessages to feed you the data more slowly?

Um, yes, I think it does... but I'd hate to have to re-edit all the old
exisiting titles when we could just put in a command line option to "slow
down the text output routines"... just a smidge. Just enough so that your
brain can actually see the text is scrolling, and not mearly jumping 10-15
lines at a time instantly.

Again, I was able to put in a few delays into the frotz source code just
playing around, but unfortuantly for me... the ncurses library "repaint" or
"refresh" or whatever was'nt refreshing often so.. while I succeeded in
slowing down the responses, the appearence of text was still flashing into
existance 5-10 lines at a time, all at once.

Heh... I even tried slowing down my stty speed to 2400 baud just for
kicks... but it didn't work... I guess the modern libraries ignore the speed
settings and just display as fast as possible...

Robb Sherwin

unread,
Oct 20, 2001, 5:26:34 PM10/20/01
to
On Sat, 20 Oct 2001 17:50:09 GMT, csha...@woh.rr.com wrote:
> The last time I played Zork II was on an NCR Decision Mate V with
>two floppy's. On that system, there just seemed to be something magical
>about going into a new room for the first time, and having to wait the 2 or
>3 seconds it took to pull the room description off the drive. I also
>remember the feeling of accomplishment at solving a puzzle for the first
>time and knowing that SOMETHING NEW was about to happen because you could
>hear and see the floppy drive going to work.

I used to love that effect, too. Playing around with Zork at night,
getting into a new room, and then having the red light of the floppy
drive kick in. Also, going from silence to the screeching of my floppy
drive whenever it tried to access some new space was like the devil
himself trying to escape the drive bay.

I think a routine to allow the new text to have that "scrolling"
effect would be useful, though -- sometimes I lose track of where I
was on the display when going into a new room. I wouldn't mind having
that as a toggle option.

Robb

=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Robb Sherwin, Fort Collins CO
Fallacy of Dawn: www.joltcountry.com/fod/dawn.zip
Reviews From Trotting Krips: members.dencity.com/petro/reviews.html

Gregg V. Carroll

unread,
Oct 20, 2001, 6:07:09 PM10/20/01
to

> On Sat, 20 Oct 2001 17:50:09 GMT, csha...@woh.rr.com wrote:

>> The last time I played Zork II was on an NCR Decision Mate V with
>> two floppy's. On that system, there just seemed to be something magical
>> about going into a new room for the first time, and having to wait the 2 or
>> 3 seconds it took to pull the room description off the drive. I also
>> remember the feeling of accomplishment at solving a puzzle for the first
>> time and knowing that SOMETHING NEW was about to happen because you could
>> hear and see the floppy drive going to work.

> I used to love that effect, too. Playing around with Zork at night,
> getting into a new room, and then having the red light of the floppy
> drive kick in. Also, going from silence to the screeching of my floppy
> drive whenever it tried to access some new space was like the devil
> himself trying to escape the drive bay.

I'll second that! I hadn't actually thought about this until I read the
original post, but I think I had sensed something subjectively "wrong" with
playing IF now as opposed to my AppleII and C128 days, and I think this is
it. I mean, you really knew something cool was going to happen when the
drive really started grinding, and you knew there was going to be at least
two or more [MORE] prompts. :)

> I think a routine to allow the new text to have that "scrolling"
> effect would be useful, though -- sometimes I lose track of where I
> was on the display when going into a new room. I wouldn't mind having
> that as a toggle option.

This is a good point. I've had to retrace my steps visually more than a few
times to find where I left off before hitting the space bar. It's even gone
so far as holding the space bar down a little too long and having multiple
[MORE] prompts in a row cycle past in the blink of an eye.

Maybe there should be a line of dashes inserted between the line before the
[MORE] prompt and the line after it, so you could visually track the break.
The downside being that it breaks the flow of text, but in the old Infocom
games, didn't the [MORE] prompt not get cleared, i.e. it scrolled up with
the text. That could work, since you could use that as a visual reference.

Gregg

Raven Kayce

unread,
Oct 20, 2001, 6:30:55 PM10/20/01
to
csha...@woh.rr.com wrote in message news:<lPiA7.5953$Fx6.2...@typhoon.columbus.rr.com>...
> On that system, there just seemed to be something magical
> about going into a new room for the first time, and having to wait the 2 or
> 3 seconds it took to pull the room description off the drive. I also
> remember the feeling of accomplishment at solving a puzzle for the first
> time and knowing that SOMETHING NEW was about to happen because you could
> hear and see the floppy drive going to work.

I have similar feelings towards HyperCard, which forced its windows to
be aligned to 8-pixel boundaries horizontally so it would draw faster.
Whenever I use a program that also does this, it makes the program
feel much more stable and robust to me (because HyperCard was). But I
have to say I wouldn't want every program to do these jumps when
moving a window.

Same here. Generally slowing down the entire text output would be a
Bad Idea(tm). But maybe they could add a new command that introduces
the beginning of a new "section". This would then scroll the next text
output to the top of the screen slowly (that is, slow enough so it is
really visible what is going offscreen and what new text is coming),
getting rid of previous text at the same time. This would be nice for
larger location changes or a new chapter in the story.

Just my $0.02

-- Raven

Daniel Dawson

unread,
Oct 20, 2001, 7:30:36 PM10/20/01
to
You pick up and read article <3bd1ea6c.148315377@news>, written by Robb Sherwin

<bea...@zombieworld.com>. It says:
>On Sat, 20 Oct 2001 17:50:09 GMT, csha...@woh.rr.com wrote:
>> The last time I played Zork II was on an NCR Decision Mate V with
>>two floppy's. On that system, there just seemed to be something magical
>>about going into a new room for the first time, and having to wait the 2 or
>>3 seconds it took to pull the room description off the drive. I also
>>remember the feeling of accomplishment at solving a puzzle for the first
>>time and knowing that SOMETHING NEW was about to happen because you could
>>hear and see the floppy drive going to work.
>
>I used to love that effect, too. Playing around with Zork at night,
>getting into a new room, and then having the red light of the floppy
>drive kick in. Also, going from silence to the screeching of my floppy
>drive whenever it tried to access some new space was like the devil
>himself trying to escape the drive bay.
>
>I think a routine to allow the new text to have that "scrolling"
>effect would be useful, though -- sometimes I lose track of where I
>was on the display when going into a new room. I wouldn't mind having
>that as a toggle option.

I agree with most of this. Well, one thing I don't miss is having to mess with
those floppies, especially when they had to be swapped. But I do agree that
being able to slow down the text output would both be useful and appeal to
nostalgia.

Don't make it just a toggle, though. Allow the player to set the amount of
delay!
--
Daniel Dawson
dda...@nospam-altavista.net (remove 'nospam-' to send mail)
http://www.crosswinds.net/~ddawson/

Robotboy8

unread,
Oct 20, 2001, 7:46:19 PM10/20/01
to
Who needs this petty "scroll slowly" thing. I'm thinking someone should write
an libraries for both Inform and TADS that would actually make the floppy drive
spin and such... probably quite imposiible, but I would agree. I got into IF
late, very late - but my first experience with it was an Macintosh 68k rewrite
of Adventure, and it was slow. (It was AGT, so of course it was slow.) I am
by now means suggesting all IF be written under AGT from now on, just that I
liked the feeling...

My second experience with IF was borrowing a friend's Zork 5 1/4s and playing
it on a piece of junk DOS machine from 1980. But ahh, the nostalgia...
Wait a minute, that was just 5 years ago! Oh well, it really did feel better.

--
If I say so then it is so; if it is so, it's probably because I said so.

csha...@woh.rr.com

unread,
Oct 20, 2001, 8:28:31 PM10/20/01
to
Robotboy8 <robo...@aol.com> wrote:
> Who needs this petty "scroll slowly" thing. I'm thinking someone should write
> an libraries for both Inform and TADS that would actually make the floppy drive
> spin and such... probably quite imposiible, but I would agree. I got into IF
> late, very late - but my first experience with it was an Macintosh 68k rewrite
> of Adventure, and it was slow. (It was AGT, so of course it was slow.) I am
> by now means suggesting all IF be written under AGT from now on, just that I
> liked the feeling...

Well, I suppose we could always copy the .dat file to an actuall floppy and
run the z-machine against that...

--- 3 minutes later ---

Nope, didn't work. My OS is too advanced. It cached the whole file on the
first opening, and never went back to the disk. Hmm.. maybe if I turn off
the read and write caching.... hmmm...

--- 1 minute later ---

Nope, no good... although that did cause the drive to activate every time I
went into a new room, the text still instantly appeared on the screen.
There's got to be a way...

csha...@woh.rr.com

unread,
Oct 20, 2001, 8:29:48 PM10/20/01
to
Matthew Russotto <russ...@wanda.pond.com> wrote:
> In article <lPiA7.5953$Fx6.2...@typhoon.columbus.rr.com>,
> <csha...@woh.rr.com> wrote:
>>
>> Comments anyone?

> Yeah, I swear I've read this article already, a long time ago.

So what was the consensus from the last time? Come on, share with the rest
of the class. :)

Robb Sherwin

unread,
Oct 20, 2001, 10:20:58 PM10/20/01
to
On Sun, 21 Oct 2001 00:28:31 GMT, csha...@woh.rr.com wrote:
>Nope, no good... although that did cause the drive to activate every time I
>went into a new room, the text still instantly appeared on the screen.
>There's got to be a way...

Just a guess -- we had 64KB of RAM on the old Commodore 64, and
(something like) 128K on the original PCs -- while I'm pretty sure
that the Zork .dat file is around 100KB you might be able to get that
effect to appear if you limit / lower the amount of available
conventional memory.

(Er, presuming you're currently using an x86-descended PC and all.)

dgr...@cs.csuabk.edu

unread,
Oct 20, 2001, 10:18:38 PM10/20/01
to

Hmm... Maybe add sounds to the game consisting of floppy drive noises...
especially the loud rattles that would send some drives scooting around
the desk.


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

Adam Thornton

unread,
Oct 20, 2001, 11:52:17 PM10/20/01
to
>Don't make it just a toggle, though. Allow the player to set the amount of
>delay!

Clearly we need a command-line option, with 0 being the default.

And someone needs to digitize that Disk ][ "gronk, gronk" noise and
play it after some commands.

Adam

Daniel Barkalow

unread,
Oct 21, 2001, 1:42:39 AM10/21/01
to
On Sat, 20 Oct 2001 csha...@woh.rr.com wrote:

> Provided that there's a way around ncurses or terminfo's or
> whatever, buffering the screen output all-at-once, it shouldn't be too hard
> to put in a command line option for somekind of "delay" between output
> lines.

The reason you don't see the text scroll up the screen is that frotz
doesn't refresh the screen until it wants input, at which point it
repaints the whole screen in place. For Unix frotz 2.40 (the version I
haapen to have the source to in front of me), add the line
"refresh();" just before the last line of ux_screen.c

I tried it myself (P2 ~300 in an xterm under linux 2.4), and while it must
only add a few milliseconds, it is perceptually very different, since the
text actually moves through the intermediate points on the screen. This
doesn't make it take any time to display text, though, so the text on
the first page after a screen clear appears instantly, and if it figures
out that the text it is printing will replace the whole screen, it just
erases it and starts from the top. It probably wouldn't be hard to make it
not notice, but I'm not quite up to figuring it out right now.

I think the effect is actually kind of nice, at least when it's not over a
slow network connection. It definitely gives a quick visual clue as to
location of the beginning of the new text.

-Iabervon
*This .sig unintentionally changed*

Daniel Dawson

unread,
Oct 21, 2001, 4:06:46 AM10/21/01
to
You pick up and read article <f4314a46.01102...@posting.google.com>,

written by Raven Kayce <ka...@gmx.net>. It says:
>Generally slowing down the entire text output would be a
>Bad Idea(tm).

Again, I disagree with this. But I think it's best to let users decide whether
they want it or not. So, just include it as an option, okay?

Daniel Dawson

unread,
Oct 21, 2001, 4:06:50 AM10/21/01
to
You pick up and read article
<Pine.LNX.4.21.011021...@iabervon.org>, written by Daniel

Barkalow <iabe...@iabervon.org>. It says:
>On Sat, 20 Oct 2001 csha...@woh.rr.com wrote:
>I tried it myself (P2 ~300 in an xterm under linux 2.4), and while it must
>only add a few milliseconds, it is perceptually very different, since the
>text actually moves through the intermediate points on the screen. This
>doesn't make it take any time to display text, though, so the text on
>the first page after a screen clear appears instantly, and if it figures
>out that the text it is printing will replace the whole screen, it just
>erases it and starts from the top. It probably wouldn't be hard to make it
>not notice, but I'm not quite up to figuring it out right now.

Ah yes. I was forgetting how [n]curses acts. It doesn't seem to like scrolling
at all, even though I'm sure about every term type supports it. (Instead, it
uses a sort of top-down refreshing algorithm.) The ANSI type, for instance,
allows an application to define a scrollable range on the screen; when the
cursor is inside, text output is scrolled within that range while everything
else stays in place. I don't know if [n]curses ever uses that feature these
days.

As for the erasing-the-screen behavior, that's also done by [n]curses: part of
the refreshing algorithm compares the old contents with the new contents, and
tries to update the screen efficiently; if a significant block will be the
same, it just skips over that, whereas if a whole line or what remains of it is
changing, it just sends an erase-line control (at least with ANSI) followed by
the new content.

If you're wondering how I know the above, it's not from studying source code or
anything. I used to use lynx over a 1200 modem! :) On such a slow connection,
one is thankful to have the refreshing done as efficiently as possible.

ibel

unread,
Oct 21, 2001, 4:19:24 AM10/21/01
to
If we gloss over graphical semi-IF (like the early Sierra games, Kings Quest
etc), text adventures have used the same command line teletype interface
ever since Adventure. The only thing that's really changed is the speed at
which the text is displayed--it's lost the rhythm evident when playing Zork
on a C64 with a buzzing floppy drive. As a recent thread in this very forum
proves, there are people who miss the sluggish scroll speeds and delays.

I propose giving text adventures back their rhythm--and kicking it up a
notch. Imagine IF output that was based less on a teletype and more on an
animated e.e.cummings poem.

A question mark could be timed to morph into an exclamation point. The text
that scrolls off screen could be salted with paranoid statements for the
player who bothers to use the scrollbars to discover. A special room
description could print out colored to transparency, slowly words fade into
view and piece themselves together.

A runic font could be used to display alien text when the player types, "x
alien document". When the player types "wear magic glasses", all the normal
text in the game becomes garbled, all the alien text readable--right there
on the screen real-time.

When the player uses an in-game computer (type on keyboard) the game would
switch to a second teletype--black background and glowing green letters.
When the player typed in a normal command (go east) the original teletype
would return: it's scroll back intact. A similar system could be used when
switching between characters, or switching between a reoccurring flashback
and present tense. Each "section" of the game would maintain it's own
scollback. There might even been a nifty transition between

Instead of just erasing the screen, we could blur it...eventually fading to
white--or apply a host of other transition effects.

Last but not least, the scroll speed could be controlled dependant upon the
situation. During an exciting scene, the scroll would be hyper quick. For
a much more melancholy feel, the scroll speed could start off slow and only
get slower as the description drags on. A sudden pause mid-scroll can
create tension. Maybe the scroll speed could even be matched to a piece of
music...

I'm certain that there are other minds on this newsgroup that can think of
applications both more useful and more dramatic.

None of these effects would work well on a palm-pilot. In fact, one of the
reasons I've thought about using a Director/z-machine combo is that
Shockwave is at least somewhat portable and the author could still easily
release a pure text version (sans multimedia tags) for the palm-pilot and
Unix peeps.

For a while now I've been thinking about porting the Z-machine to Macromedia
Director. Stopping me is the piss-poor bit manipulation featured in vanilla
Lingo and the glacial speed of outputting text in Director. The idea was to
include special tags (much like HTML-TADS) in a story for a Director Lingo
script to interpret.

Another big problem with Director is that it's the opposite of free. Plus,
it's ability to manipulate text leaves something to be desired--some of the
effects described above would be difficult to conjure with Director.

So, I've more or less given up on the idea of porting the z-machine to
Lingo. I'm wondering about Glulx--I realize that many of the effects are
outside of glx's reach--but at least the variable scroll speed should be
achievable (easy even).

Has anyone else thought about this sort of thing?

John Elliott

unread,
Oct 21, 2001, 6:03:53 AM10/21/01
to
csha...@woh.rr.com wrote:
>There's got to be a way...

Use ZXZVM (my interpreter for Z80-based systems) under JOYCE (which
emulates an Amstrad PCW), and make JOYCE use the real floppy drive.

ZXZVM: <http://www.ifarchive.org/indexes/if-archiveXinfocomXinterpretersXspectrum.html>
JOYCE: <http://www.seasip.demon.co.uk/Unix/Joyce/>

(but you will also need genuine PCW boot discs - for reasons of c*pyright,
I can't supply these).

If you don't have PCW boot discs, and can do without the fun of hearing
the floppy drive grind, then use ZXZVM in a Spectrum+3 emulator.

--
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)

TheCycoONE

unread,
Oct 21, 2001, 10:21:34 AM10/21/01
to

"Robb Sherwin" <bea...@zombieworld.com> wrote in message
news:3bd23098.5972083@news...

> On Sun, 21 Oct 2001 00:28:31 GMT, csha...@woh.rr.com wrote:
> >Nope, no good... although that did cause the drive to activate every time
I
> >went into a new room, the text still instantly appeared on the screen.
> >There's got to be a way...
>
> Just a guess -- we had 64KB of RAM on the old Commodore 64, and
> (something like) 128K on the original PCs -- while I'm pretty sure
> that the Zork .dat file is around 100KB you might be able to get that
> effect to appear if you limit / lower the amount of available
> conventional memory.
>
> (Er, presuming you're currently using an x86-descended PC and all.)
>
> Robb
>
Well for the Infocom games you can download them all for a commodore
emulator, turn on True Drive Emulation, and live it up. Some (though not
very many) emulators go so far as to make some of the drive noise, and most
show a little red light in the bottom right corner of the screen
coresponding to that on the old 1541.

(see www.commodorezone.com)

csha...@woh.rr.com

unread,
Oct 21, 2001, 3:59:17 PM10/21/01
to
Daniel Dawson <dda...@nospam-altavista.net> wrote:
>>Generally slowing down the entire text output would be a
>>Bad Idea(tm).

> Again, I disagree with this. But I think it's best to let users decide whether
> they want it or not. So, just include it as an option, okay?

Yes, too slow would be bad. We don't want to slow the text down to the
point of where the player can read faster than the screen. I just wanted to
make the text advance at more stately pace rather than a whole paragraph
instantly appearing between raster sweeps on my monitor. :)

So, I'm please to announce, that I was hacking on pinfocom-3.0 last night,
and added exactly this function. There's a new command line option "-d #"
that allows the user to specify the new-line delay in milliseconds.
(1/1000th's) of a second increments. 0 is the default, but values of 5-20
can REALLY mimick the old systems.

I've gone and changed the man pages, the Makefile, and added in the option
to the MSDOS, and stream and termcap display options, (although I've only
tested the termcap one on my linux box)... and it works GREAT!

So I popped a few new notes into the README's and upped the version to 3.1.
(it's really such a minor change I feel it should be more like 3.01, but it
*IS* a new feature... so I guess 3.1 is the right number.

Or... we could be like microsoft and call it V7 for no apparent reason. :)

Now, the question is... will the original maintainer want to kick my ass for
making this change or what? -- I did send out an email to him asking his
input... but the email address in the README was dated 1993 so it's no
suprise that it bounced...

pinfocom is a PD file, so there's no legal issues with making the
changes... but I wouldn't want to piss anybody off.

Anywho... I'd be happy to post the pinfocom-3.1.src.tar.gz file somewhere...
but it seems all the freaking ftp sites have locked down their incoming
directories. Where's a guy supposed to post this stuff? :)

Daniel Dawson

unread,
Oct 21, 2001, 8:03:30 PM10/21/01
to
You pick up and read article <tt5mb7f...@corp.supernews.com>, written by
TheCycoONE <cyc...@hotmail.com>. It says:
>Some (though not
>very many) emulators go so far as to make some of the drive noise,

Really? Wow.

>and most
>show a little red light in the bottom right corner of the screen
>coresponding to that on the old 1541.

One emulator I tried (DOS) used the PC's Scroll Lock light, which I thought
looked rather amusing on the MS Natural keyboard. (All three indicators are in
a column between the two halves of the split alphanumeric section.)

Daniel Dawson

unread,
Oct 21, 2001, 8:03:31 PM10/21/01
to
You pick up and read article <tt518m...@corp.supernews.com>, written by
ibel <not...@for.now>. It says:
>So, I've more or less given up on the idea of porting the z-machine to
>Lingo. I'm wondering about Glulx--I realize that many of the effects are
>outside of glx's reach--but at least the variable scroll speed should be
>achievable (easy even).

What?? You're giving up on the Z-machine, yet you want to try Glulx, which I
think is feature-wise a superset of the Z-machine? Perhaps you could explain
your thinking, or something I've missed.

David Glasser

unread,
Oct 21, 2001, 8:57:17 PM10/21/01
to
<csha...@woh.rr.com> wrote:

> So, I'm wondering if anyone else has felt something similar in the
> new z-machines? And I propose a question to the Z-Machine developers...
> Would it be very difficult to put a few usleep(); calls into the text print
> routines that slow down the display just a little bit?

You should try zonk... it is exactly what you need!

http://www.davidglasser.net/zonk/

--
David Glasser
ne...@davidglasser.net http://www.davidglasser.net/

Branko Collin

unread,
Oct 21, 2001, 10:10:57 PM10/21/01
to
csha...@woh.rr.com, you wrote on Sun, 21 Oct 2001 19:59:17 GMT:

>Now, the question is... will the original maintainer want to kick my ass for
>making this change or what? -- I did send out an email to him asking his
>input... but the email address in the README was dated 1993 so it's no
>suprise that it bounced...
>
>pinfocom is a PD file, so there's no legal issues with making the
>changes... but I wouldn't want to piss anybody off.

If it literally says "Puplic Domain", the original author has
relinquished all power over it. If it says nothing about distribution
or being freeware or PD etc., the author retains _all_ rights.
Copyrights can only be signed away explicitely, just as a license can
only be explicit (well, that last bit has not been tested in courts
AFAIK -- which seems to be important in the case of Usenet and
groups.google.com, for instance).

>Anywho... I'd be happy to post the pinfocom-3.1.src.tar.gz file somewhere...
>but it seems all the freaking ftp sites have locked down their incoming
>directories. Where's a guy supposed to post this stuff? :)

<ftp://ftp.if-archive.org> ?

--
branko collin
col...@xs4all.nl

Daniel Barkalow

unread,
Oct 21, 2001, 10:24:22 PM10/21/01
to
On Sun, 21 Oct 2001, Daniel Dawson wrote:

> You pick up and read article
> <Pine.LNX.4.21.011021...@iabervon.org>, written by Daniel
> Barkalow <iabe...@iabervon.org>. It says:
> >On Sat, 20 Oct 2001 csha...@woh.rr.com wrote:
> >I tried it myself (P2 ~300 in an xterm under linux 2.4), and while it must
> >only add a few milliseconds, it is perceptually very different, since the
> >text actually moves through the intermediate points on the screen. This
> >doesn't make it take any time to display text, though, so the text on
> >the first page after a screen clear appears instantly, and if it figures
> >out that the text it is printing will replace the whole screen, it just
> >erases it and starts from the top. It probably wouldn't be hard to make it
> >not notice, but I'm not quite up to figuring it out right now.
>
> Ah yes. I was forgetting how [n]curses acts. It doesn't seem to like
> scrolling at all, even though I'm sure about every term type supports
> it. (Instead, it uses a sort of top-down refreshing algorithm.) The ANSI
> type, for instance, allows an application to define a scrollable range
> on the screen; when the cursor is inside, text output is scrolled within
> that range while everything else stays in place. I don't know if
> [n]curses ever uses that feature these days.

The issue is actually simply that curses only updates the screen when told
to, and then updates it with all of the changes since the last update. If
it's never told to updates while part of the paragraph has been printed,
that intermediate stage will never appear. Even if it uses the region
scrolling feature, what you'll see is the region scrolled by n lines, and
then the lines filled in afterward, which is not the nice effect (it's
faster to scroll only the existing lines, and then write new lines in the
right place than write each new line at the bottom and scroll it).

> As for the erasing-the-screen behavior, that's also done by
> [n]curses: part of the refreshing algorithm compares the old contents
> with the new contents, and tries to update the screen efficiently; if a
> significant block will be the same, it just skips over that, whereas if
> a whole line or what remains of it is changing, it just sends an
> erase-line control (at least with ANSI) followed by the new content.

Again, this is really a matter of frotz not telling curses to display the
text after writing a single line, and frotz telling curses to erase the
text area when no existing text will remain on the screen. The curses
behavior is only relevant as the method used to go from one update to the
next-- if the program does not tell it to display partially moved text, it
generally won't, and certainly won't allow the program to wait for a
little while with the text between specified appearences.

> If you're wondering how I know the above, it's not from studying source
> code or anything. I used to use lynx over a 1200 modem! :) On such a
> slow connection, one is thankful to have the refreshing done as
> efficiently as possible.

Yeah, I've seen much that effect when having network lag from work to my
server at home.

ibel

unread,
Oct 22, 2001, 1:58:26 AM10/22/01
to
Naw,

I'm not giving up on the z-machine. I'm giving up on the idea of porting
the the z-machine to Macromedia Director's scripting language of Lingo. I'm
wondering if some of the advanced text display functionality I'm hoping for
would be possible under future versions (or the current version) of Glulx.

The sort of things I want to do do (aside from the scroll delay) are
"impossible" (er just very very difficult) in the z-machine because there is
no way for the Z to refer to or change text that's already been displayed.

For example, in order to keep two seperate scrollback logs for two different
characters in a single game your program would have to store a complete log
of everything outputted to the teletype and re-output this entire log (or
some portion of it) when the characters switch. This seems clumsy to me,
esp. since the presence of a scrollback isn't guarenteed (on an emulutor to
emulator basis). With Lingo, I'd be able to simply have two different
teletypes, perhaps varying the look and feel of these teletypes
significantly.

Basically, the question is: how much control over the output (both before
and after it hits the screen) is Glulx slated to provide?

My idea, btw, was to marry the z-machine with lingo. The story would
contain mark-up tags that would be read and acted upon by a Lingo script. A
seprate text only game file would still exist for platforms that lack
shockwave players.


Dylan O'Donnell

unread,
Oct 22, 2001, 10:37:11 AM10/22/01
to
col...@xs4all.nl (Branko Collin) writes:
> csha...@woh.rr.com, you wrote on Sun, 21 Oct 2001 19:59:17 GMT:
>
> >Now, the question is... will the original maintainer want to kick my ass for
> >making this change or what? -- I did send out an email to him asking his
> >input... but the email address in the README was dated 1993 so it's no
> >suprise that it bounced...
> >
> >pinfocom is a PD file, so there's no legal issues with making the
> >changes... but I wouldn't want to piss anybody off.
>
> If it literally says "Puplic Domain", the original author has
> relinquished all power over it. If it says nothing about distribution
> or being freeware or PD etc., the author retains _all_ rights.

pinfocom appears to be confused about its own status :-( It contains a
copy of the GNU GPL as a file COPYING in the root directory of the
source tree, as is the convention for GPL'ed projects; however, the
first sentence of the README is "This package is a public-domain
implementation of a Zork Interpretive Program (ZIP)." I suspect that,
to be on the safe side, treating it as being covered by the GPL is
best.

--
: Dylan O'Donnell http://www.spod-central.org/~psmith/ :
: "And nickel, neodymium, neptunium, germanium / And iron, americium, :
: ruthenium, uranium, / Europium, zirconium, lutetium, vanadium..." :
: -- Tom Lehrer, "The Elements" :

Andrew Plotkin

unread,
Oct 22, 2001, 10:50:59 AM10/22/01
to
ibel <not...@for.now> wrote:

> I'm not giving up on the z-machine. I'm giving up on the idea of porting
> the the z-machine to Macromedia Director's scripting language of Lingo. I'm
> wondering if some of the advanced text display functionality I'm hoping for
> would be possible under future versions (or the current version) of Glulx.

> The sort of things I want to do do (aside from the scroll delay) are
> "impossible" (er just very very difficult) in the z-machine because there is
> no way for the Z to refer to or change text that's already been displayed.

> For example, in order to keep two seperate scrollback logs for two different
> characters in a single game your program would have to store a complete log
> of everything outputted to the teletype and re-output this entire log (or
> some portion of it) when the characters switch. This seems clumsy to me,
> esp. since the presence of a scrollback isn't guarenteed (on an emulutor to
> emulator basis). With Lingo, I'd be able to simply have two different
> teletypes, perhaps varying the look and feel of these teletypes
> significantly.

> Basically, the question is: how much control over the output (both before
> and after it hits the screen) is Glulx slated to provide?

Not that much. :-)

The Glk I/O layer is very high-level -- it really is the same approach
as the V5 Z-machine, only somewhat more general in several places.
(Multiple windows, etc.) You can't refer to or change text that's
already displayed, unless you use a textgrid window (analogous to the
status window in the Z-machine).

Now, the flip side of this is that you *can* do this sort of display
customization in the Glk *library*. The Glulx game file is isolated
*above* this layer of control -- and this is a basic design feature,
not a sometimes-broken guideline as it is in the Z-machine.

It would not be hard to take the sort of interpreter hacks that have
been suggested for Z-machine interpreters, and adapt them for GlkTerm
or XGlk. (Even for CheapGlk, although it would be sort of pointless.)

However, if you look at the list of updates, bug fixes, and features
that I need to get around to for Glk, you can imagine where that would
arrive on my list of priorities. :-)

--Z

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

Davey

unread,
Oct 22, 2001, 11:42:38 AM10/22/01
to
Hi Ibel,
Some of your ideas are good. I'm glad there's someone out there who
advocates change. That's the only way to progress.

I remember playing Planetfall on a C-64, and I'll tell you that waiting for
the computer's reply gave the sense that the game was "thinking" and that
real time was passing during the course of the game. Nowadays everything is
instantaneous...which somehow doesn't have the charm that the old games
seemed to have to me.

However, I think that playing with the display fonts, colours and display
speed could be quite distracting to the player. When I read in my head, I
can gulp in sentences at a time (much like most people I suspect). I would
find it annoying to read a sentence only to have to wait for the display to
catch up to me.

To add moments where attention should be drawn to a particular sentence, we
are provided the [MORE] prompt...more than adequate to fill this role.

Also, IF isn't a book but it should read like a book--pulling you through
the physical page of text without drawing attention to the surface of the
text itself. The page is merely there as a window to ideas contained
within. An attempt to fill a page with changing fonts and colours would
only remind you that you are reading a book. Which isn't what I want in a
book or a work of interactive fiction.

So to summarize, I advocate small delays in game play before the program
spits out its' responses back to the player, but I'm not personally into
messing too much with the consistency of the text.

BUT: Try it! See how it plays! I could be completely wrong. It's up to
you to bring these ideas from the theoretical to the practical. When do you
plan to release this game?

Thanks,
D

"ibel" <not...@for.now> wrote in message
news:tt518m...@corp.supernews.com...

dgr...@cs.csuabk.edu

unread,
Oct 22, 2001, 11:57:00 AM10/22/01
to
Andrew Plotkin <erky...@eblong.com> wrote:
> ibel <not...@for.now> wrote:

>> Basically, the question is: how much control over the output (both before
>> and after it hits the screen) is Glulx slated to provide?

> Not that much. :-)

[snip]


> It would not be hard to take the sort of interpreter hacks that have
> been suggested for Z-machine interpreters, and adapt them for GlkTerm
> or XGlk. (Even for CheapGlk, although it would be sort of pointless.)

> However, if you look at the list of updates, bug fixes, and features
> that I need to get around to for Glk, you can imagine where that would
> arrive on my list of priorities. :-)

Since I'm right now replacing the old Unix Frotz screen-handler with Glk,
I'd be very interested in seeing these screen hacks. The way I'm
currently implementing it, Glk will be included in the Unix Frotz tarball.
I'm also looking at the feasability of hacking Glk to use zlib and bzlib.


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

Branko Collin

unread,
Oct 22, 2001, 1:38:16 PM10/22/01
to
psmit...@spod-central.org (Dylan O'Donnell), you wrote on 22 Oct
2001 15:37:11 +0100:

>col...@xs4all.nl (Branko Collin) writes:
>> csha...@woh.rr.com, you wrote on Sun, 21 Oct 2001 19:59:17 GMT:
>>
>> >Now, the question is... will the original maintainer want to kick my ass for
>> >making this change or what? -- I did send out an email to him asking his
>> >input... but the email address in the README was dated 1993 so it's no
>> >suprise that it bounced...
>> >
>> >pinfocom is a PD file, so there's no legal issues with making the
>> >changes... but I wouldn't want to piss anybody off.
>>
>> If it literally says "Puplic Domain", the original author has
>> relinquished all power over it. If it says nothing about distribution
>> or being freeware or PD etc., the author retains _all_ rights.
>
>pinfocom appears to be confused about its own status :-( It contains a
>copy of the GNU GPL as a file COPYING in the root directory of the
>source tree, as is the convention for GPL'ed projects; however, the
>first sentence of the README is "This package is a public-domain
>implementation of a Zork Interpretive Program (ZIP)." I suspect that,
>to be on the safe side, treating it as being covered by the GPL is
>best.

That would be my guess.

--
branko collin
col...@xs4all.nl

Brett Sanger

unread,
Oct 22, 2001, 2:11:59 PM10/22/01
to
> I propose giving text adventures back their rhythm--and kicking it up a
> notch. Imagine IF output that was based less on a teletype and more on an
> animated e.e.cummings poem.

<snip many text effects>

Everyone is entitled to their opinion, but here's mine too: These all
sound like they range from pointless to incredibly annoying. I'm sure
there are some people out there who would love to scour their
scrollback to see if there is a hidden clue, but I'm not one of them.
What value are you seeking to add to the game?

I'm not (completely :) ) blasting your ideas, I'm seeking clarity. Do
you think such effects would add puzzles to games? Improve the
ability to convey a story? create some gameplay component to make it
more involving?

(I never liked ee cummings either)

Robin Rawson-Tetley

unread,
Oct 22, 2001, 2:31:19 PM10/22/01
to
Thanks for this post - you really made me laugh out loud :)

I started out playing the Infocom games on C64 disk and it was agonisingly
slow, yet, as you say, you really "got into" them more for the fact that you
had time to properly digest the writing whilst the beige breezeblock was
grinding.

Solving a puzzle and entering a new location was treated with something akin
to a sexual thrill because you could see the disk getting punished. A few
words would appear tantalisingly on the screen, then a mere 30 seconds later
up would come your room description and you would be absolutely delighted.

I feel exactly the same way about the new Z machines and I find it does make
it much harder for me to get into new Z games. It also seems somehow to
diminish the stature of the game in my mind (ridiculous I know) because of
the speed with which it ejaculates onto my screen (not referring to earlier
sexual thrills :) - it just looks too easy - I have no respect for things
that look easy!

As you probably know, I'm that annoying bloke that wrote IAGE (I post about
it a lot :) and I shall be implementing a "C64 Infocom" feature into my
clients to produce random pauses and grinding noises during play :)

Rob

IAGE is king!
www.robin.rawsontetley.btinternet.co.uk/iage/


----- Original Message -----
From: <csha...@woh.rr.com>
Newsgroups: rec.arts.int-fiction
Sent: Saturday, October 20, 2001 6:50 PM
Subject: Opinion: Are the new Z-Machines *TOO* fast?


> All,
>
> A few weeks ago I had the pleasure of playing (well, messing around
> with, anyway) Frobnitz on a Palm M505 system. And it seemed to me, that
due to
> the limited processor and text scrolling speed of the palm device, the old
> infocom games regained a lot of their charm.
>
> Actually, what happened was the fooling around with the game
> reignited my intrest in the old games, so I installed a copy of frotz on
my
> linux box, and loaded up my old favorite Zork II.
>
> The last time I played Zork II was on an NCR Decision Mate V with
> two floppy's. On that system, there just seemed to be something magical
> about going into a new room for the first time, and having to wait the 2
or
> 3 seconds it took to pull the room description off the drive. I also
> remember the feeling of accomplishment at solving a puzzle for the first
> time and knowing that SOMETHING NEW was about to happen because you could
> hear and see the floppy drive going to work.
>
> It seems as though that feeling has been lost a little bit with the
> new Z-Machine interpreters. They're so darn fast that solving a puzzle,
or
> entering a room you just left is handled with the same result. A belch of
> text that suddenly pops up on the screen so fast you hardly have time to
> notice that the screen has even scrolled at all.
>
> Now, granted, the designers of the infocom games would probably have
> been elated over the speed at which their games run now, but it just seems
> to me that a little of the soul has been lost.
>
> As the old saying goes, "the devil's in the details", even todays
> blackjack and other card-games, try to "smoothly" animate the dealing of
> cards, even though it's just as easy to make the new cards suddenly appear
in
> your hand. It's almost as if the wetware in our heads "needs" details
like
> blinking cards, or smooth animation in order to processes the fact that
"Oh,
> yeah, *THIS* item has moved from here to there"
>
> As an avid player of gnuChess, I find it MUCH easier to interpret
> moves when the chess-men blink, first, or slide into place as opposed to
> simply popping into their new positions.


>
> So, I'm wondering if anyone else has felt something similar in the
> new z-machines? And I propose a question to the Z-Machine developers...
> Would it be very difficult to put a few usleep(); calls into the text
print
> routines that slow down the display just a little bit?
>

> I'm certainly not advocating a return to a 300 baud text-printing
> mechanism, but just a slight slowing down, so that we can actually see the
> screen scroll as apposed to simply advancing 5-10 lines of text instantly?
>
> I'm not the worlds greatest programmer, but I did try playing with
> the source-code to frotz a little bit, and I stuck in some usleep calls
> between the buffer_flush() and new_line() calls, but unfortunatly the
> ncurses or maybe xterm's output algorithms were working against me, and
what
> I would up with was just a total-pause after hitting return, and then a
> jump-scroll of the whole text. I couldn't get the output text to pop-up
> line by line.


>
> Provided that there's a way around ncurses or terminfo's or
> whatever, buffering the screen output all-at-once, it shouldn't be too
hard
> to put in a command line option for somekind of "delay" between output
> lines.
>

> But, then maybe I'm the only one who feels this way.
>
> Oh, yeah... turning off jump-scroll in my xterm doesn't have any
> real effect. On a genuine VT terminal, I could always enable
> smooth-scroll... but even that *really* isn't the same thing...
>
> Comments anyone?
>
>
>
>

Joe Mason

unread,
Oct 22, 2001, 2:22:08 PM10/22/01
to
In article <9r1fkc$1fqkg$1...@hades.csu.net>, <dgr...@cs.csuabk.edu> wrote:
>Since I'm right now replacing the old Unix Frotz screen-handler with Glk,
>I'd be very interested in seeing these screen hacks. The way I'm
>currently implementing it, Glk will be included in the Unix Frotz tarball.
>I'm also looking at the feasability of hacking Glk to use zlib and bzlib.

I'm not sure what you mean by "Glk will be included". It's an interface
definition. Do you mean some particular Glk library will be included?

If you dump the old screen model completely, how will you handle V6? Will
there be V6 and Glk subsystems, instead of the current V6 and curses? (Or
will Frotz be Glk and XFrotz still the old interface?)

I'm also not sure what zlib and bzlib have to do with Glk.

Joe

dgr...@cs.csuabk.edu

unread,
Oct 22, 2001, 6:45:51 PM10/22/01
to
Joe Mason <jcm...@student.math.uwaterloo.ca> wrote:
> In article <9r1fkc$1fqkg$1...@hades.csu.net>, <dgr...@cs.csuabk.edu> wrote:
>>Since I'm right now replacing the old Unix Frotz screen-handler with Glk,
>>I'd be very interested in seeing these screen hacks. The way I'm
>>currently implementing it, Glk will be included in the Unix Frotz tarball.
>>I'm also looking at the feasability of hacking Glk to use zlib and bzlib.

> I'm not sure what you mean by "Glk will be included". It's an interface
> definition. Do you mean some particular Glk library will be included?

The way it's looking now, a Glk library (right now just glkterm) will be
included in the tarball and linked in statically.

> If you dump the old screen model completely, how will you handle V6? Will
> there be V6 and Glk subsystems, instead of the current V6 and curses? (Or
> will Frotz be Glk and XFrotz still the old interface?)

So far, it seems that Alemic's code for handling graphics on a terminal
will work through Glk. Andrew claims that image display works for xGlk,
but I'll be looking at that later. Eventually I plan to release a source
tree than can produce the following:

tfrotz: Uses glkterm and displays only to terminals.

xfrotz: Uses xGlk to display to X11 using Athena widgets.

kfrotz: Uses a Qt widgets with the option of hooking into KDE.

gfrotz: Uses GTK widgets with the option of hooking into GNOME.

All of these will support sound through either libsndfile or audiofile
(haven't decided which) for samples. I really don't know how mods will be
handled given the ones recently discussed don't seem to be under active
development. The latter three will have full V6 support. Classic-mode
sound and graphics will be disabled and from then on Blorb will be the
only way to do sound and graphics. I think there's a script somewhere to
convert the old picture files into something acceptable to Glk.

Other nice things would be to have it compile to MacOSX, BeOS, and
QNX using native GUIs.

> I'm also not sure what zlib and bzlib have to do with Glk.

The way I understand how Glk handles loading the game file (which isn't
very good ATM), there doesn't appear to be a way to make it open a gzipped
or bzip2ed file. I've had several requests for such an ability to be
added.


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

ibel

unread,
Oct 23, 2001, 1:36:24 AM10/23/01
to

> I'm not (completely :) ) blasting your ideas, I'm seeking clarity. Do
> you think such effects would add puzzles to games? Improve the
> ability to convey a story? create some gameplay component to make it
> more involving?
>

I can spew on for days with ideas for Easter Eggs and FX. FX can be poorly
done and annoying just like anything else. From my experiences playing HTML
Tads games, the best philosophy seems to be to use pictures and sounds
sparringly...special text effects would also have to be used carefully--just
adding a bit of spice without overwhelming the experience.

Potential uses of having greater control over the elements that make up an
IF user interface:
1: Real time auto-complete of commands. As the player types, the interface
tries to guess what command the player is trying to issue. The suggested
text completing the player's command appears as dark grey. Pressing the
left arrow key accepts the next word in the suggested auto complete.
Although this could be done by a z-machine interpreter itself, since it has
access to the object tree and dictionary, the auto complete could be much
smarter if it was implemented by the story itself.

2: Allowing Oops and Undo to actually amend the previously spewed output. It
would be as if the amended actions never occured in their original forms.
This may or may not be a desirable behavior, so there should be a switch to
turn it off.

3: Modal dialog windows for certain in game questions that require an
immediate answer. For example, "Game Over! Restart, Quit, Undo, or View the
Author's End Game Notes?" could appear as a dialog box instead of being a
part of the terminal's transcript. Other in game questions that break the
fourth wall might also work better as modal dialogs.

4: Hotspot roll overs. Mouse users would be able to roll over pieces of
text to get a Tool tip style blurb, or perhaps a picture of the target
object.

The truth is, designing puzzles has never been my strong point. I'm
thinking more of using text FX for atmosphere. I'm 100% positive that
somebody somewhere can come up with IF syle puzzles that incorporate text FX
in a meaningful way.

I think I'm going to build my own little text adventure parser in Macromedia
Director just for the purposes of building a single game that's been
swimming around in my head for the past 10 years. But, a more robust,
reusable solution to the "problem" of giving authors greater control over
text elements is going to require some rethinking on my part. Sooner or
later I'm going to read through the glx source and see if there's something
I can do with it.

In the end, if I really want to do all the things that I'm thinking of doing
(including some NPC and simulationist stuffs) I'm probably going to have to
construct my own custom program in C--everything else is just going to be
too slow.


Marcus

unread,
Oct 23, 2001, 10:09:43 AM10/23/01
to
I couldn't agree more!
Marc

Kevin Bracey

unread,
Oct 23, 2001, 11:59:31 AM10/23/01
to
In message <Xns91439C2A...@ID-99504.news.dfncis.de>
Karl Ove Hufthammer <huf...@bigfoot.com> wrote:

> I'm having problems with this when I'm using WinFrotz. If the text
> after the 'MORE'-prompt spans an entire page, then there's no
> problem -- I should start reading at the top of the
> page/window/screen. But when the text is less than a page high,
> and suddenly appears, and I don't know where I should start
> reading.
>
> Scrolling would really help here. I don't need (nor want) very
> slow scrolling (thirty seconds to display a paragraph). Half a
> second to display a screenful, perhaps? Even nicer would be pixel
> at a time scrolling (i.e., 'smooth scrolling') instead of line at
> a time scrolling.

I'd agree that scrolling is very important. In Zip 2000 I very deliberately
ensure that as a block of text appears, all intermediate scroll positions are
briefly visible, by forcing a window update after every single-line scroll. I
find interpreters that don't update the screen until the scrolling is
complete very disconcerting.

Unfortunately on many windowing systems, the window will often not be updated
until the machine is next idle, unless the interpreter takes special action.

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

Joe Mason

unread,
Oct 23, 2001, 2:05:31 PM10/23/01
to
In article <9r27iv$1ftsg$1...@hades.csu.net>, <dgr...@cs.csuabk.edu> wrote:

>Joe Mason <jcm...@student.math.uwaterloo.ca> wrote:
>> I'm not sure what you mean by "Glk will be included". It's an interface
>> definition. Do you mean some particular Glk library will be included?
>
>The way it's looking now, a Glk library (right now just glkterm) will be
>included in the tarball and linked in statically.

That'd be convenient, I suppose. But let me share with you my vision of the
One Try Way to distribute Glk apps (on Unix, at least):

The Glk Central Committee (or the Debian Glk maintainer, or Red Hat, or whoever)
provides a set of easy-to-install Glk packages for GlkTerm, XGlk, etc.
The user picks their favourite, and installs it, where it dumps its shared
libraries in /usr/lib (or whereever we decide the Standard Place should be)
and dumps a GlkLoader config file for itself in /etc/glkloader.d. Or, um,
something like that - I can't remember where GlkLoader looks by default.

Now Frotz statically links with GlkLoader. When you install it, it checks for
the existence of /etc/glkloaderrc. If it's there, assume the user's already
configured GlkLoader. If not, write out a glkloaderrc that tells it to try
Glk libraries in this order: XGlk, GlkTerm, CheapGlk.

So, from the user's point of view, you just do this:

$ rpm -Uvh glkterm
$ rpm -Uvh frotz
$ frotz

Frotz starts, tries to load XGlk. Fails - XGlk isn't installed. Tried
GlkTerm, succeeds, and it works.

If the user installs xglk as well, suddenly that works with Frotz too. If
the user installs xglk, but tries to start frotz from the console, it falls
back to GlkTerm again.

Or if the user installs a brand new Glk library that you don't even know about,
it also works with Frotz. Assuming it sticks all its config files in the same
place the Glk Central Committee decided to put them for the rest of the Glk
libraries, all the user will have to do is add it to the list of libraries in
glkloaderrc.

Under Debian, it's even easier for the user, because the package dependencies
would presumably be set up so that "apt-get frotz" also grabs the best
available Glk package if its not already installed.

The advantage for this is that the maintainer of every Glk app doesn't have to
explicitly link it with every possible library. You gave a huge list which
I unfortunately snipped. To be complete, the TADS maintainer and the Hugo
maintainer and the Alan maintainer and everybody has to manage the same type
of list. If you use GlkLoader, you don't have to care about
any of that - let the Glk Central Committee worry about making it work with
KDE and Gnome and stuff like that.

>development. The latter three will have full V6 support. Classic-mode
>sound and graphics will be disabled and from then on Blorb will be the
>only way to do sound and graphics. I think there's a script somewhere to
>convert the old picture files into something acceptable to Glk.

I thought Glk's screen model and the V6 screen model were too different for
that?

Joe

csha...@woh.rr.com

unread,
Oct 23, 2001, 6:12:59 PM10/23/01
to
Karl Ove Hufthammer <huf...@bigfoot.com> wrote:

> I'm having problems with this when I'm using WinFrotz. If the text
> after the 'MORE'-prompt spans an entire page, then there's no
> problem -- I should start reading at the top of the
> page/window/screen. But when the text is less than a page high,
> and suddenly appears, and I don't know where I should start
> reading.

Yes, that's exactlty how I felt.

> Scrolling would really help here. I don't need (nor want) very
> slow scrolling (thirty seconds to display a paragraph). Half a
> second to display a screenful, perhaps? Even nicer would be pixel
> at a time scrolling (i.e., 'smooth scrolling') instead of line at
> a time scrolling.

Well, you could always try to find an old vt220 terminal in a rummage sale
and hook it up to your linux box. at 19200 Baud, it's fast enough, but all
DEC VT terminals have a setup option that turns on smooth-scroll (single
pixel advance)... it's nice, smooth.. and ... almost spooky.

But, on another note, I've already put the code into pinfocom, using a
user-configurable -d option. I've updated the man page, the versions on all
the files, the documentation, the changelog... Everything I could find.
I tar'd the whole thing up, gzip'd it; Pinfocom V3.1 is ready to roll...
Unfortunatly I don't have anyplace to post it to. All the archives seem to
have disabled their incomming directories... or they have
upload-instructions that reference incoming directories that no longer
exist.

So what's a guy have to do to post a new version? --Any site maintainers
out there who might send me upload instructions that aren't 3 years out of
date? :)

--Me

Kevin Forchione

unread,
Oct 23, 2001, 6:43:19 PM10/23/01
to
"ibel" <not...@for.now> wrote in message
news:tta0f0f...@corp.supernews.com...

> In the end, if I really want to do all the things that I'm thinking of
doing
> (including some NPC and simulationist stuffs) I'm probably going to have
to
> construct my own custom program in C--everything else is just going to be
> too slow.

This is probably the case, since the leading IF development systems adhere
to a fairly time-honored convention, both in the way they display and in the
model worlds they implement. They'e flexible to a certain degree, but
shouldn't be expected to accomodate everything. They strive to maintain a
balance appropriate to the beginner and the advanced author alike. And
should you develop something of which the community at large finds
interesting or beneficial, I'm sure they will incorporate these ideas into
their own models.

Good luck!

--Kevin


Greg Ewing

unread,
Oct 23, 2001, 9:15:23 PM10/23/01
to
ibel wrote:
>
> 2: Allowing Oops and Undo to actually amend the previously spewed output. It
> would be as if the amended actions never occured in their original forms.

No, you have to find the Wand of Balefire to
enable that option. :-)

--
Greg Ewing, Computer Science Dept, University of Canterbury,
Christchurch, New Zealand
To get my email address, please visit my web page:
http://www.cosc.canterbury.ac.nz/~greg

Adam Thornton

unread,
Oct 23, 2001, 11:39:40 PM10/23/01
to
In article <9r27iv$1ftsg$1...@hades.csu.net>, <dgr...@cs.csuabk.edu> wrote:
>The way it's looking now, a Glk library (right now just glkterm) will be
>included in the tarball and linked in statically.

Eeeeeeagh! Don't *do* this!

>So far, it seems that Alemic's code for handling graphics on a terminal
>will work through Glk. Andrew claims that image display works for xGlk,
>but I'll be looking at that later. Eventually I plan to release a source
>tree than can produce the following:
>tfrotz: Uses glkterm and displays only to terminals.
>xfrotz: Uses xGlk to display to X11 using Athena widgets.
>kfrotz: Uses a Qt widgets with the option of hooking into KDE.
>gfrotz: Uses GTK widgets with the option of hooking into GNOME.

And also look at the various sound patches for Linux.

Adam

David Given

unread,
Oct 24, 2001, 6:33:25 AM10/24/01
to
In article <9r4bhb$nof$1...@watserv3.uwaterloo.ca>,
jcm...@student.math.uwaterloo.ca (Joe Mason) writes:
[...]

>>The way it's looking now, a Glk library (right now just glkterm) will be
>>included in the tarball and linked in statically.
>
> That'd be convenient, I suppose. But let me share with you my vision of the
> One Try Way to distribute Glk apps (on Unix, at least):
>
> The Glk Central Committee (or the Debian Glk maintainer, or Red Hat, or whoever)
> provides a set of easy-to-install Glk packages for GlkTerm, XGlk, etc.
> The user picks their favourite, and installs it, where it dumps its shared
> libraries in /usr/lib (or whereever we decide the Standard Place should be)
> and dumps a GlkLoader config file for itself in /etc/glkloader.d. Or, um,
> something like that - I can't remember where GlkLoader looks by default.

Actually, I'm working right now on Debianising glk. I was going to wait
until it was done before saying anything, but if people are thinking of
packaging it up seperately, I'd better say something now or we'll
duplicate effort.

What I'm doing is having a package, libglk0 (and libglk-dev) that contaisn
your glkloader (nice piece of work, BTW). Applications dynamically link to
this. Then you have one or more glk implementations, libglk-x or
libglk-term or libglk-cheap.

This would mean that there *would* be a single, centralised libglk, to
which applications would link. It just wouldn't actually do anything.

What I currently don't have is a centralised rc file describing all the
installed glk implementations, because your existing code doesn't support
it; I was hoping to be able to use unmodified upstream archives. I've
managed this with glkloader but I think I'll need a different approach on
other packages. As I say, everything's still in a state of flux.

The other thing I'm not sure I can do is have a single method of doing
"apt-get install nitfol" and have it Just Work. libglk0 will Suggest
libglk0-x, etc, but I'm not entirely sure whether Suggests are installed
automatically by apt-get install. I still need to look into this.

Eventually it'll show up in a nice apt repository on cowlark.com or
plover.net, assuming I work out how the hell apt repositories work.

--
+- David Given --------McQ-+ "`Aplysia californica' is your taxonomic
| Work: d...@tao-group.com | nomenclature.
| Play: d...@cowlark.com | A slug, by any other name, is still a slug by
+- http://www.cowlark.com -+ nature." --- drushel on a.f.c

Robin Rawson-Tetley

unread,
Oct 24, 2001, 8:32:30 AM10/24/01
to
Since reading this, the IAGE client now has an "8-bit emulation mode" which
you can enable to relive the good old days :-)

www.robin.rawsontetley.btinternet.co.uk/iage/


<csha...@woh.rr.com> wrote in message
news:lPiA7.5953$Fx6.2...@typhoon.columbus.rr.com...

Alan DeNiro

unread,
Oct 24, 2001, 1:08:47 PM10/24/01
to
swif...@alumni.psu.edu (Brett Sanger) wrote in message news:<5bf8fa17.0110...@posting.google.com>...

I'm not sure about the animation of text per se, but one practical
application I can think of is with an Infidel-style game, with
deciphering hieroglyphs, or ideograms, or whatever. That would
certainly heighten the realism, especially if there was some way to
indicate or record which letters or phrases of the code have been
"solved," and showing the translated/untranslated text accordingly.

Actually, does HTML-TADS allow for font embedding? That might be a
cleaner way to go about it, but it certainly doesn't address the
graphical/"artistic" issues proposed.

I don't know if ee cummings is the best example for what you're
talking about? Maybe Kenneth Patchen?

Alan

Joe Mason

unread,
Oct 24, 2001, 4:41:58 PM10/24/01
to
In article <ld56r9...@172.16.100.66>,

David Given <d...@pearl.tao.co.uk> wrote:
>What I'm doing is having a package, libglk0 (and libglk-dev) that contaisn
>your glkloader (nice piece of work, BTW). Applications dynamically link to
>this. Then you have one or more glk implementations, libglk-x or
>libglk-term or libglk-cheap.

Thanks.

I started writing because I wanted to do the Debian packaging myself. Then
Daniel Schepler made some suggestions, cause he was thinking of Debianizing
it, and he's a registered Debian developer to boot. So you're in good company.

One thing I dislike about it right now is that if you try to run under the
console, you get error messages as it tries to load X and fails and then moves
on to the console version. It'd be a lot neater to do this silently. (Try
starting with a bad command line and watch it spit usage messages at you
several times.)

>This would mean that there *would* be a single, centralised libglk, to
>which applications would link. It just wouldn't actually do anything.

Yeah, that makes sense on Debian because the dependency tracking works so
smoothly. For a tarball or RPM-based setup, I think it makes sense to
statically link GlkLoader and avoid the extra layer of indirection.

>What I currently don't have is a centralised rc file describing all the
>installed glk implementations, because your existing code doesn't support
>it; I was hoping to be able to use unmodified upstream archives. I've
>managed this with glkloader but I think I'll need a different approach on
>other packages. As I say, everything's still in a state of flux.

I'm not sure what you mean here. AFIAK, the code *does* support a
centralised rc file. What it doesn't support is an easy way for
newly-installed Glk libraries to register themselves in that file.

If you list uninstalled Glk libraries in the central rc file, all you get is
that it would fail to open and move on to the next. I guess when you install a
new Glk librbary it could add it to the end of the defaults list, but what if
you actually want it to be first in the list?


>The other thing I'm not sure I can do is have a single method of doing
>"apt-get install nitfol" and have it Just Work. libglk0 will Suggest
>libglk0-x, etc, but I'm not entirely sure whether Suggests are installed
>automatically by apt-get install. I still need to look into this.

I believe they are.

I was thinking of a slightly more complex scheme, actually. Nitfol would
"Require glk" and "suggest glk-multimedia", while GlkTerm would "provide glk"
and xglk would "provide glk" and "provide glk-multimedia". You could even
get more fine-grained to list specific features (although this duplicates the
gestalt system a little too much for my taste).

Individual games like the Zeta Space demo could "Require glk-multimedia" if
they needed those features, or even "Require glk-transparent-pngs". But
nobody wants to take the time to debianize every single game, and the whole
thing would get a little cumbersome by that point anyway.

Joe

ibel

unread,
Oct 25, 2001, 2:40:33 AM10/25/01
to

>
> I'm not sure about the animation of text per se, but one practical
> application I can think of is with an Infidel-style game, with
> deciphering hieroglyphs, or ideograms, or whatever. That would
> certainly heighten the realism, especially if there was some way to
> indicate or record which letters or phrases of the code have been
> "solved," and showing the translated/untranslated text accordingly.

Good idea!

This would actually be pretty easy to do just using HTML TADs. The
hieroglyphs could just be image tags, although a second font would probably
produce more predictable results on screens with different resolutions. As
far as I can tell, HTML TADS doesn't currently support author defined fonts.

If the author had more control over the interface, he would be able to set a
system for typing in ideograms--so the player would be able to refer to the
strange writing without having to come up with a unique adjective for each
character, ie, "lookup swirly goddess hieroglyph on rosetta stone." In
addition, if the auhtor deemed it a desireable behavior, translated
hieroglyphs could appear in english (or whatever) in the previous output
(both on the screen and in the scrollback). So, if the player read a wall
covered with hieroglyphs 50 turns ago and then translates some of them, he
could scroll back to when he read the wall and see the partial translation.

It would also be possible to toggle between viewing the hieroglyphs and
translated text--just in case the actual pictures had some sort of in-game
meaning. Maybe you can put them together like a jigsaw to make a map to the
buried treasure...? The act of piecing together a jigsaw is much much
easier with a drag drop interface, rather than typing "move swirly goddess
hieroglyph to the left". With total control over the interface, an IF
author could implement this one puzzle using sprites instead of text
elements.

Two things spring to mind:

A: if HTML TADs implemented java script and layers, both the jigsaw puzzle
and the translation of hieroglyphs in the output would be possible. It
would muddy the waters quite a bit to squeeze layers and javascript into
HTML TADS, probably not the best solution.

B: Java is a mutli-platform virual machine, just like the Z and glx. Why
not, instead of making custom VMs like t3 and glulx, build a comprehensive
IF library for Java? A coder/author could then delve into the nitty gritty
details at will...personally, I don't think Java is any harder to learn than
Inform. It's certainly easier to learn than C.

hmmm.

I know that there are already people making IF with Java--what we need is a
standardize comprehensive IF library that's relatively easy for the typical
Inform coder to learn. Perhaps something that's semi-based off of Inform
library...


Joe Mason

unread,
Oct 25, 2001, 2:15:14 PM10/25/01
to
In article <ttfcvdl...@corp.supernews.com>, ibel <not...@for.now> wrote:
>A: if HTML TADs implemented java script and layers, both the jigsaw puzzle
>and the translation of hieroglyphs in the output would be possible. It
>would muddy the waters quite a bit to squeeze layers and javascript into
>HTML TADS, probably not the best solution.

Er, I don't see what gain comes from layering another scripting language on
top of the TADS code that's driving the output anyway. (Actually, I do - if
you output "scripted" elements to the display, you can then update them. But
why not just use TADS code as the script?) Layers I'm not familiar with.

>B: Java is a mutli-platform virual machine, just like the Z and glx. Why
>not, instead of making custom VMs like t3 and glulx, build a comprehensive
>IF library for Java? A coder/author could then delve into the nitty gritty
>details at will...personally, I don't think Java is any harder to learn than
>Inform. It's certainly easier to learn than C.

Java's just the most "famous" virtual machine, due to Sun's marketing. Other
good languages with VM's are Smalltalk and Python. (Python, being a scripting
language with some fair text-processing capability, is a natural choice for IF,
and there's already an IF system called PAWS for it.)

The attraction of making a special-purpose IF machine is that it can be made
small enough - and limited enough in features - that it can be easily ported
to platforms like the Palm and such that only support subsets of Java, and to
archaic hardware that people have for nostalgia that nobody in their right
mind would port Java too.

There's no reason not to make a Java library, I just don't see why. Java's
just a buzz-word. I'd prefer to see more work on PAWS if you want to use a
general VM - I only looked at it briefly, but it seems to be a good start but
a little limited still. (Also, you can use Jython - a Python implementation in
Java - to run PAWS games on a Java VM.)

Joe

David Given

unread,
Oct 25, 2001, 6:43:38 AM10/25/01
to
In article <9r792m$2h$1...@watserv3.uwaterloo.ca>,

jcm...@student.math.uwaterloo.ca (Joe Mason) writes:
[...]
> I started writing because I wanted to do the Debian packaging myself. Then
> Daniel Schepler made some suggestions, cause he was thinking of Debianizing
> it, and he's a registered Debian developer to boot. So you're in good company.

One of the reasons I'm doing it is because I want to become a registered
developer; and I need a masterwork (something I can give my sponsor to
show I know what I'm doing).

Hopefully I'll have something downloadable this weekend.

[...]


> I'm not sure what you mean here. AFIAK, the code *does* support a
> centralised rc file. What it doesn't support is an easy way for
> newly-installed Glk libraries to register themselves in that file.

Ah. I didn't know this; the documentation just mentions ~/.glkloader. I'll
have a look at the source.

> If you list uninstalled Glk libraries in the central rc file, all you get is
> that it would fail to open and move on to the next. I guess when you install a
> new Glk librbary it could add it to the end of the defaults list, but what if
> you actually want it to be first in the list?

I think the simplest solution for now would be to have a static list in
some configuration file somewhere, held by libglk0 itself. Once I know the
rest of it's working, then it's time to start fiddling with postinst
scripts. (And won't *that* be fun.)

[...]


> I was thinking of a slightly more complex scheme, actually. Nitfol would
> "Require glk" and "suggest glk-multimedia", while GlkTerm would "provide glk"
> and xglk would "provide glk" and "provide glk-multimedia". You could even
> get more fine-grained to list specific features (although this duplicates the
> gestalt system a little too much for my taste).

Hmm. Possible.

I'll have to think about this one.

--
+- David Given --------McQ-+

| Work: d...@tao-group.com | No lawyers were harmed in the creation of this
| Play: d...@cowlark.com | post. I'll try harder next time.
+- http://www.cowlark.com -+

Knight37

unread,
Oct 25, 2001, 3:11:00 PM10/25/01
to
csha...@woh.rr.com had the moxy to write:

> Robotboy8 <robo...@aol.com> wrote:
>> Who needs this petty "scroll slowly" thing. I'm thinking someone
>> should write an libraries for both Inform and TADS that would actually
>> make the floppy drive spin and such... probably quite imposiible, but
>> I would agree. I got into IF late, very late - but my first
>> experience with it was an Macintosh 68k rewrite of Adventure, and it
>> was slow. (It was AGT, so of course it was slow.) I am by now means
>> suggesting all IF be written under AGT from now on, just that I liked
>> the feeling...
>
> Well, I suppose we could always copy the .dat file to an actuall floppy
> and run the z-machine against that...
>
> --- 3 minutes later ---
>
> Nope, didn't work. My OS is too advanced. It cached the whole file on
> the first opening, and never went back to the disk. Hmm.. maybe if I
> turn off the read and write caching.... hmmm...
>
> --- 1 minute later ---
>
> Nope, no good... although that did cause the drive to activate every
> time I went into a new room, the text still instantly appeared on the
> screen. There's got to be a way...
>

Use Moslo. Turn that gigahertz into a mega hurts.

--

Knight37

Agent Smith: We're willing to wipe the slate clean, give you a fresh start.
All that we're asking in return is your cooperation in bringing a known
terrorist to justice.
Neo: Yeah. Well, that sounds like a pretty good deal. But I think I may have
a better one. How about, I give you the finger... and you give me my phone
call.
-- "The Matrix"

Joe Mason

unread,
Oct 25, 2001, 4:47:23 PM10/25/01
to
In article <qcq8r9...@172.16.100.66>,

David Given <d...@pearl.tao.co.uk> wrote:
>> I'm not sure what you mean here. AFIAK, the code *does* support a
>> centralised rc file. What it doesn't support is an easy way for
>> newly-installed Glk libraries to register themselves in that file.
>
>Ah. I didn't know this; the documentation just mentions ~/.glkloader. I'll
>have a look at the source.

Er. I hope I actually implemented it, then. I'll take a look - um, this
weekend, I hope.

Joe

Daniel Dawson

unread,
Oct 26, 2001, 12:35:33 AM10/26/01
to
You pick up and read article <ttfcvdl...@corp.supernews.com>, written by
ibel <not...@for.now>. It says:
>B: Java is a mutli-platform virual machine, just like the Z and glx. Why
>not, instead of making custom VMs like t3 and glulx, build a comprehensive
>IF library for Java?

>personally, I don't think Java is any harder to learn than
>Inform.

But unlike Inform, it's quite bloated. I mean, it's a nice system, but I think
it's overkill for IF. The whole idea of the Z-machine has been to have a system
specifically optimized for IF. How many virtual machines (or indeed computers)
allow you to print a whole string or input a whole line (with automatic case
conversion) with a single instruction? Oh well. I guess if you want to try
Java...
--
Daniel Dawson
dda...@nospam-altavista.net (remove 'nospam-' to send mail)
http://www.crosswinds.net/~ddawson/

Reply all
Reply to author
Forward
0 new messages