Newsgroups: rec.arts.int-fiction,rec.games.int-fiction
Path: nntp.gmd.de!news.ruhr-uni-bochum.de!news-koe1.dfn.de!news-kar1.dfn.de!news.nacamar.de!www.nntp.primenet.com!nntp.primenet.com!news.mindspring.com!uunet!in2.uu.net!208.198.253.36!news.kesmai.com!rich
From: rich@muddy.kesmai.com ()
Subject: Question of opinion
Sender: usenet@news.kesmai.com (USENET news)
Message-ID: <E2I63q.436@news.kesmai.com>
Date: Mon, 16 Dec 1996 10:50:14 GMT
X-Nntp-Posting-Host: ns1.kesmai.com
Organization: Kesmai
Lines: 46
Xref: nntp.gmd.de rec.arts.int-fiction:19213 rec.games.int-fiction:19279

Working on WinFrotz 2.0 brought up some interesting design issues I thought I
would ask people about, because it might affect the direction of the
development.

My design goal was to make a shell that surrounded the original Frotz code and
only changed the device-dependent functions that Stefan intended to be edited.
The reason for this was simple: Frotz works well and if it is modified, I could 
integrate the new code in a snap. I didn't want to rewrite any substantial 
portions of Stefan's code basically.

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

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?). Also graphical versions would be
hopeless.

Is it more important to preserve the compatibility or provide the convienance
features of a rollback buffer? What do people think? 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.

-Rich

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, how would
you distinguish between the two if so, 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).

