On Mon, 22 Mar 2004, Hubert Feyrer wrote:

> On Mon, 22 Mar 2004, der Mouse wrote:
> > > So I was thinking, what if we replaced our curses library with
> > > ncurses?
> > I thought this had already been done, quite some time ago.
>
> No. The concensus was to not use ncurses, but do the 1-time work of fixing
> whatever is needed in our curses to have a standard-compliant & free
> curses version.

Differences between ncurses and NetBSD's curses has been a constant source
of trouble for my development of Frotz.  Here is a list of stuff from my
BUGS file.  Hopefully someone may point out something I missed.

1) It seems that it's up to the curses library to decide if a program may
or may not use color.  For example, if you use compile Frotz to use
ncurses on a NetBSD machine, it won't let you use color on an xterm.
Why?  Xterm on NetBSD uses termcap, and for some funny reason ncurses
doesn't want to play nice with termcap.

2) Under ncurses, getch() will return OK (defined to 0 ) when Ctrl-@ or
Ctrl-Space is pressed.  0 is also the ZSCII character code for
ZC_TIME_OUT.  This causes a fatal error "Call to non-routine", after which
Frotz aborts.  This doesn't happen with all games nor is the crashing
consistent.  Sometimes repeated tests on a single game will yield some
crashes and some non-crashes.  When linked with ncurses, we must make sure
that unix_read_char() does not return a bogus ZC_TIME_OUT.  This returning
of 0 appears to be abnormal behavior peculiar to ncurses, so an #ifdef is
used to enable the fix only if ncurses is being used.  Alembic's fix
didn't have this #ifdef and so it broke NetBSD's newly-updated curses
library.



-- 
David Griffith
dgriffi@cs.csubak.edu