Newsgroups: rec.arts.int-fiction,rec.games.int-fiction
Path: nntp.gmd.de!Dortmund.Germany.EU.net!Germany.EU.net!EU.net!howland.erols.net!www.nntp.primenet.com!nntp.primenet.com!netcom.com!erkyrath
From: erkyrath@netcom.com (Andrew Plotkin)
Subject: Re: [Z-machine] Question of opinion
Message-ID: <erkyrathE2Ip5L.Dqz@netcom.com>
Followup-To: rec.arts.int-fiction,rec.games.int-fiction
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
X-Newsreader: TIN [version 1.2 PL1]
References: <E2I63q.436@news.kesmai.com>
Date: Mon, 16 Dec 1996 17:41:45 GMT
Lines: 98
Sender: erkyrath@netcom.netcom.com
Xref: nntp.gmd.de rec.arts.int-fiction:19414 rec.games.int-fiction:19401

rich@muddy.kesmai.com wrote:
> I pulled this off through some Win32 trickery using threads - the Z-machine 
> runs as an independent thread from the GUI, with a couple of data pipes for
> I/O (screen, keyboard)...but I digress. To create the most compatible version 
> possible, one that allowed me to only modify device-dependent code, I've more
> or less locked myself out of a) significant scrollback buffers and b)possibly
> cut and paste (for the Windows/MFC minded, I derived directly from CView and
> draw it myself. I cannot use CRichEditView or CEditView and maintain 100% 
> compatibility with Frotz - email me if you want to the reasons).

I'm sort of curious, but I know nothing about MFC. Feel free to post an 
explanation if you can simplify it for us [voluntary] Windows-illiterates.

The design of xzip/MaxZip/MaxTADS, for comparison, has the interpreter 
engine "on top" of the event loop. The engine calls 
os_dependent_read_line(), or whatever, and that starts up a little event 
loop, which sucks keyboard and mouse events until the user hits Enter. 
Then the little event loop exits. 

This is a totally old-fashioned, single-threaded way of doing things, but 
it is legal in X windows and Mac System 7 -- as long as you don't use any 
fancy-schmancy application class library. :-) I doubt I could get it to 
work with Motif (not that I know anything about Motif) or the 
pure-event-driven model planned for Mac System 8 (not that Copland/System 
8 is going anywhere these days.)

I may try to figure out an alternate approach, say in Java.

> Anyway I COULD make a version that had a long scrollback buffer and would 
> probably support everything you're used to in, say, Wordpad (note that I do
> already support edit keys, just not cut and paste). If I do this I will almost
> certainly sacrifice some compatibility with quirky games like Seastalker or
> Bureaucracy (the fill out form, remember?). 

Those are really not much problem. Seastalker is just a very large status
line; it's not harder than box quotes (and trust me, you can't get away
without box quotes.) Bureaucracy is text input in the status line. 
It's a series of read_char opcodes, so all you really have to do is 
handle those normally. Making an input mark appear in the status line is 
nice but not necessary. 

As long as the main window knows to buffer user keystrokes until the
interpreter asks -- which it must do in any case, since it doesn't know
whether the interpreter will ask via read_line or read_char -- read_char
doesn't display the typed character, remember -- you'll be fine. 

> Also graphical versions would be
> hopeless.

I have never tried writing a version 6 Z-interpreter.

> Is it more important to preserve the compatibility or provide the convienance
> features of a rollback buffer? What do people think?

When not in a V6 game, I definitely vote for convenience (as you can tell 
by the amount of programming time I spend on it.) 

> As I played certain games
> I couldn't help noticing that the presentation - the sizing of the paragraphs,
> even the spacing of more prompts - was more or less built around an 80 col
> line. Even with WinFrotz now you can go full screen with an Arial font and
> get 200+ chars on a line - just doesn't look the same. I found myself going 
> back to a more or less 80x25 layout (only with a big honking easy to read
> font). I was curious what other folks thought about this.

Well, a very wide text window looks bad in any application (when
displaying normal prose text.) It makes the paragraphs too long and
skinny. I like text windows to be about 80 or 100 characters wide, and
proportioned like a piece of paper, which means 40 to 50 lines high. (I
just started an xzip and sized it the way I like it, and counted. And my
shell and Emacs windows are the same.)

I find a 25-line text window painfully cramped in any circumstances.

> P.S. For those up on the specs of the Z-machine, you're probably thinking it
> wouldn't be too hard to have the scrollback just capture what appears in a
> "buffered" window, namely window 0. You're probably also right. Three questions
> arise: are there any games that buffer windows OTHER than 0,

In non-V6 games, window 0 is always a buffer and window 1 is a
non-buffering fixed-width character grid. In V6, again, I am clueless. 

> and what do you do with games that 
> send to the buffered window stuff that really shouldn't be (small example: AMFV
> sticks the "[Press any key to continue]" message from the title screen in the
> buffered output - annoying).

You live with it. Heh. My interpreters just leave the "hit any key" 
message visible, since there's nothing they can do about it. If the game 
clears the screen right away, it's not a big deal, and if not, well, it's 
still not a big deal.

--Z

-- 

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
