89 lines
3.5 KiB
Plaintext
89 lines
3.5 KiB
Plaintext
=============
|
|
Color mode ||
|
|
=============
|
|
|
|
It seems that it's up to the curses library to decide if a program may
|
|
or may not use color. For example, ncurses on NetBSD refuses to allow
|
|
Frotz to run in color mode, even when color mode is forced. Frotz and
|
|
the program it's running think color is being emitted, but ncurses won't
|
|
allow it. On the other hand, NetBSD's standard curses library (1.6 and
|
|
later) will let colors be seen.
|
|
|
|
|
|
=======================================
|
|
Ctrl-Space causing Bogus ZC_TIME_OUT ||
|
|
=======================================
|
|
|
|
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.
|
|
|
|
|
|
|
|
=======================
|
|
Bug-testing Programs ||
|
|
=======================
|
|
|
|
Unix Frotz now comes with crashme, TerpEtude, gntests, strictz, and
|
|
Unicode Test. These are intended to excercise the interpreter and
|
|
verify that it is functioning according to spec. You will find these
|
|
programs in the src/test/ directory.
|
|
|
|
|
|
|
|
==================
|
|
Screen Resizing ||
|
|
==================
|
|
|
|
There are some significant problems involved in getting screen resizes (as
|
|
in resizing an xterm) to work correctly at least with Frotz's
|
|
implementation of the Z-Machine and probably the Z-Machine standard
|
|
itself. For this reason, I have not implemented screen resizing for
|
|
Frotz. I know that some zcode interpreters are able to deal with resizes
|
|
somewhat gracefully, but I haven't seen one yet that will handle some
|
|
weirder situations. Infocom's "Border Zone" and "Beyond Zork are
|
|
especially troublesome for doing resizes. Nitfol seems to have the best
|
|
handling of screen resizes. Since it uses the Glk library, I'm inclined
|
|
to think the Glk library is at least partially responsible. If you have
|
|
any other ideas on how to cleanly resize screens, I'd like to hear them.
|
|
|
|
The Z-Machine seems to assume that when the screen dimensions are set,
|
|
they will never change over the course of the game, even across saves and
|
|
restores. For some reason, saves include screen dimensions and I've yet
|
|
to discover how to override the Z-Machine from setting its dimensions to
|
|
the saved ones instead of how the current screen really is. When the
|
|
Z-Machine was first defined by Infocom, this made sense since terminal
|
|
screens rarely, if ever, changed their dimensions and few people were
|
|
assumed to trade saves across platforms.
|
|
|
|
|
|
|
|
=====================
|
|
Arrow Key Handling ||
|
|
=====================
|
|
|
|
Not really a bug, but an idiosyncracy. In "Journey", sometimes you can't
|
|
use the right-arrow key to move from the "party commands" menu to the
|
|
"individual commands" menu. IMHO, this is a bit sloppy, but it isn't
|
|
Frotz's fault. Instead, use the spacebar to jump from menu to menu.
|
|
I mistakenly attributed this to an unknown bug. That'll teach
|
|
me to do bugtesting when I'm about to nod off to sleep.
|
|
|
|
|
|
|
|
===================
|
|
Other Known Bugs ||
|
|
===================
|
|
|
|
Sound flag is not being set properly.
|
|
|
|
|