# Define your optimization flags.
#
# These are good for regular use.
-OPTS = -O2 -fomit-frame-pointer -falign-functions=2 -falign-loops=2 -falign-jumps=2
+#OPTS = -O2 -fomit-frame-pointer -falign-functions=2 -falign-loops=2 -falign-jumps=2
# These are handy for debugging.
-#OPTS = -O2 -g -Wall
+OPTS = -O2 -g -Wall
+
# Define where you want Frotz installed (typically /usr/local).
#
$(CURSES_DIR)/ux_text.o \
$(CURSES_DIR)/ux_blorb.o \
$(CURSES_DIR)/ux_audio.o \
- $(CURSES_DIR)/ux_resource.o
-# $(CURSES_DIR)/ux_audio_none.o \
+ $(CURSES_DIR)/ux_resource.o \
+ $(CURSES_DIR)/ux_audio_none.o
DUMB_DIR = $(SRCDIR)/dumb
DUMB_TARGET = $(SRCDIR)/frotz_dumb.a
OPT_DEFS = -DCONFIG_DIR="\"$(CONFIG_DIR)\"" $(CURSES_DEF) \
-DVERSION="\"$(VERSION)\""
-CURSES_DEFS = $(OPT_DEFS) $(COLOR_DEFS) $(SOUND_DEF) $(MEMMOVE_DEF)
+CURSES_DEFS = $(OPT_DEFS) $(COLOR_DEFS) $(NO_SOUND) $(MEMMOVE_DEF)
FLAGS = $(OPTS) $(CURSES_DEFS) $(INCL)
-SOUND_LIB = -lao -ldl -lm -lsndfile -lvorbisfile -lmodplug
+ifeq ($(NO_SOUND), )
+ SOUND_LIB = -lao -ldl -lm -lsndfile -lvorbisfile -lmodplug
+endif
$(NAME): $(NAME)-curses
+++ /dev/null
-I heartily encourage people to create packages to make it easier for less
-computer-savvy people to use Frotz. However, I do have a few rules on
-this.
-
-1. Email me if you wish to put Unix Frotz into something like a .deb,
- .rpm, Slackware package, the NetBSD pkgsrc tree, FreeBSD's ports
- tree, or anything like that. When you do so I can note that on the
- Unix Frotz webpage at http://www.cs.csubak.edu/~dgriffi/proj/frotz.
-
-2. DO NOT have auto-install programs or scripts grab files from that
- page. The Interactive Fiction Archive at http://www.ifarchive.org
- has mirrors around the world for that sort of thing.
-
-3. If you distribute a patched version, SEND ME THE PATCHES. If you
- don't tell me what bugs you've found and fixed, I can't very well fix
- those bugs in the main codebase for all the other users of Frotz.
- Patches that simply change around options in the Makefile obviously
- don't apply.
-
+++ /dev/null
-Frotz is a very portable program and as such has been ported to quite a
-lot of different platforms.
-
-
-These are actively-maintained ports and their webpages (if known):
-------------------------------------
-
-WinFrotz
-Frotz for machines running Microsoft Windows.
-http://www.d.kinder.btinternet.co.uk
-
-AmigaFrotz
-Frotz for the Amiga series of computers.
-(no webpage)
-
-FrotzCE
-Frotz for PocketPC machines running WindowsCE.
-http://www.pyram-id.demon.co.uk/FrotzCE.html
-(Based on 2.32)
-
-DOS
-Good ol' DOS
-(no webpage)
-
-Kwest
-Frotz ported to KDE.
-http://users.pandora.be/peter.bienstman/kwest/
-
-EbmFrotz
-Frotz ported to Franklin's eBookman.
-http://www.twpo.com.au/cwarrens/ebm
-
-
-
-Nobody maintains these ports:
------------------------------
-
-Pilot Frotz
-Frotz for Palm Pilot machines.
-http://www.geocities.com/SiliconValley/Way/2367/
-(Link has been dead for several months)
-
-
-
-Frotz might work well with these platforms:
--------------------------------------------
-
-Apple IIgs.
-I'm fairly sure that with its greater memory capacity than the ealier
-members of the Apple II family, at least text-mode Frotz should be
-doable. Perhaps even graphics and sound could be done.
-
-RISC/OS
-I don't see why not.
-
-Texas Instruments TI-92 and TI-92+ graphing calculators:
-With a Motorola 680000 of some sort and loads of nifty development
-software, it should be a worthwhile effort. Look at
-http://www.ticalc.org or all sorts of interesting things that have been
-done with this calculator.
-
-CP/M:
-Usually we'll have a 64 kilobyte limit to memory. Fortunately there is
-a solution in the form of an interpreter written in Z80 assembly called
-ZXZVM available at the IF Archive. It seems specific to the Spectrum
-+3, PCW16, and PCW10 CP/M machines. I'd be most pleased if someone with
-one of those new IMSAI Series 2 machines is able to get ZXZVM working on
-that machine. However, at http://www.imsai.net, the new machine is
-described as having 1 meg of static system memory. Given all this,
-Frotz might be doable on some more beefy CP/M machines.
-
-
-Frotz probably won't work on these platforms:
----------------------------------------------
-
-Apple II:
-The IIe and IIc with expanded memory (at least 143k) might be enough for
-running up to V5, but I'm not sure if Frotz will appreciate working in
-such a small space. Yes, I know that several Solid Gold editions were
-released for Apple II.
-
-Commodore 64:
-Memory is limited to a bit less than 64 kilobytes. In the heyday of
-Infocom, the C64 could barely support V4 games.
-
-Commodore 128:
-Probably same troubles as with Apple II.
-
-Atari 8-bit:
-Probably troubles as with the Commodore 64.
-
-Wireless phones:
-They might have enough memory to handle Frotz, but I have severe doubts
-about how usable any sort of Interactive Fiction can be on such a
-device. Phones were not designed to be used as general-purpose
-terminals.
-
-Digital cameras:
-Someone ported the venerable arcade machine emulator MAME to a Kodak
-digital camera some time ago. There should be enough space and
-processing power to run Frotz, but as with wireless phones, IF is
-impractical on such a platform.
-
-
-I asked Brian Moriarty, author of several works of Interactive Fiction
-for Infocom about the feasability of porting Frotz to machines using the
-MOS 6502 (Apple II, Atari 8-bit, Commodore 64 and 128). Here is his
-response to my emailed question:
-
-
-Date: Thu, 8 Aug 2002 18:54:51 -0400
-From: Brian Moriarty <prof@ludix.com>
-To: Dave <dgriffi@cs.csubak.edu>
-Subject: RE: porting Frotz to 6502 machines
-
-The original 6502 ZIPs were hand-written in assembler, and
-the resulting binaries were usually quite small (around 8k).
-Of course, a C compiler wouldn't be quite as efficient.
-
-The larger problem is that many of the later Z features (beyond
-version 2) simply won't work on an Atari, C64 or Apple II,
-either due to RAM, display or disk drive restrictions. When moving
-into versions 3 and beyond, we decided to leave that class of
-machine behind.
-
------Original Message-----
-From: Dave [mailto:dgriffi@cs.csubak.edu]
-Sent: Thursday, August 08, 2002 6:43 PM
-To: prof@ludix.com
-Subject: porting Frotz to 6502 machines
-
-
-
-Brian Moriarty,
-
-I was wondering if I could pick your brain a bit on Z-machine portability.
-One of the ongoing goals for the Frotz project is extreme portability,
-including to all sorts of old architectures. I've been pondering porting
-Frotz to 6502 machines such as the C64, Apple II, and Atari 8-bit
-computers. Doing some investigation with the CC65 6502 C compiler brought
-me to the conclusion that Frotz would produce a binary too large to fit in
-the memory of these machines. Apple IIgs might work. Given your work on
-making Z-machine interpreters for these machines (albeit in assembly, I
-assume) would this be an accurate assumption?
-
-Also, given what I've found out about the new upcoming IMSAI Series 2
-machine, this might be capable of handling Frotz.
-
-
-
+++ /dev/null
-===============================================
------------------------------------------------
-| Speech synthesis and recognition in Frotz |
------------------------------------------------
-===============================================
-
-This is highly-experimental code being commissioned by a presently
-undisclosed party. When complete, Frotz (at least for Linux and NetBSD)
-will speak its output and accept voice for input. The libraries being
-used to do this are Flite and Sphinx2. Public release in any meaningful
-way is on hold until the project is complete and I have been paid. In
-case you're wondering, this voice-enabled version of Frotz will appear
-as another make target in the Unix Frotz tarball.
-
-
-Flite (http://cmuflite.org/) is a small run-time speech synthesis engine
-created by Carnegie Mellon University around 1999. It's intended as a
-lightweight substitute for University of Edinburgh's Festival Speech
-Synthesis System and CMU's Festbox project. Flite is somewhat based on
-Festival, but requires neither of those systems to compile and run. At
-first I wanted to use Festival for voice output, but this quickly became
-impractical for various reasons (like the fact it only outputs to NAS).
-
-
-Sphinx2 (http://www.speech.cs.cmu.edu/sphinx/) is also from Carnagie
-Mellon. It is unique among voice-recognition schemes with which most
-people are familiar in that it doesn't need to be trained. That's
-right. Joe Blow can walk in off the street, talk to a program using
-Sphinx, and be understood. The tradeoff is that the programmer must
-know beforehand what words are to be recognized. This makes it
-difficult, if not impossible for voice-input to be used for arbitrary
-games. The game's dictionary must be parsed and a pronunciation guide
-made. This must be done manually because of the way the Z-machine
-recognizes words. Because it only cares about the first six letters, a
-real person must check for words longer than six letters, figure out
-what the rest of the letters are, and how the words should be
-pronounced. This is the core of the problem of supporting arbitrary
-games. A computer cannot "know" what a story is about in order to guess
-what the remaining letters are.
-
-You've probably encountered programs that do voice recognition like
-Sphinx does without realizing it. The most common example I can think
-of is how many locales handle collect calls. You get a phone call and
-an obviously recorded voice says something like the following:
-
- You have a collect call from <caller speaks name>.
- To accept the charges, please say "yes".
-
-That program is expecting to hear "yes" and is configured with several
-ways that "yes" might be constructed. For good measure, "yeah", "yep",
-"yup", "uh-huh", "alright", "okay", and other affirmatives are probably
-programmed in there too. I don't know. I haven't checked.
/*
- * ux_audio_none.c - Unix interface, sound support
+ * ux_audio.c - Unix interface, sound support
*
* This file is part of Frotz.
*
#define __UNIX_PORT_FILE
+#ifndef NO_SOUND
+
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
struct sigaction sa;
int dead_child;
-// dead_child = wait(&status);
- dead_child = waitpid(-1, &status, WNOHANG);
+ dead_child = wait(&status);
if (dead_child == sfx_pid)
sfx_pid = 0;
exit(0);
}
+
+#endif /* NO_SOUND */
*/
#define __UNIX_PORT_FILE
+#ifdef NO_SOUND /* don't compile this unless we're using no audio */
#ifdef USE_NCURSES_H
#include <ncurses.h>
#include "ux_frotz.h"
-#ifdef NO_SOUND /* don't compile this unless we're using no audio */
/*
* os_beep
/*
* ux_blorb.c - Blorb routines
- * David Griffith <dave@661.org>
*
* This file is part of Frotz.
*
#define PATH1 "ZCODE_PATH"
#define PATH2 "INFOCOM_PATH"
-#define NO_SOUND
-#ifdef OSS_SOUND
-# undef NO_SOUND
-#endif
/* Some regular curses (not ncurses) libraries don't do this correctly. */
#ifndef getmaxyx
/*
* ux_init.c - Unix interface, initialisation
- * Galen Hazelwood <galenh@micron.net>
- * David Griffith <dgriffi@cs.csubak.edu>
*
* This file is part of Frotz.
*
if (optind != argc - 1) {
printf("FROTZ V%s\t", VERSION);
-#ifdef OSS_SOUND
- printf("oss sound driver, ");
-#endif
-#ifdef USE_NCURSES
- printf("ncurses interface.");
-#else
- printf("curses interface.");
+#ifndef NO_SOUND
+ printf("Audio output enabled.");
#endif
putchar('\n');
strncpy(f_setup.aux_name, f_setup.story_name, strlen(f_setup.story_name) + 1);
strncat(f_setup.aux_name, EXT_AUX, strlen(EXT_AUX));
-/*
- printf("f_setup.story_file %s\n", f_setup.story_file);
- printf("f_setup.story_name %s\n", f_setup.story_name);
- printf("f_setup.story_path %s\n", f_setup.story_path);
-*/
-
-
}/* os_process_arguments */
/*
printf("Blorb file loaded, but lacks executable chunk.\n\n");
break;
case bb_err_None:
- printf("No blorb errors.\n\n");
+// printf("No blorb errors.\n\n");
break;
}
-// ux_initsound();
-// os_start_sample(5, 8, 1, 0);
-// os_start_sample(4, 8, 1, 0);
-// os_start_sample(3, 8, 1, 0);
-// exit(1);
-
- printf("Loading %s\n", f_setup.story_file);
-
fp = fopen(f_setup.story_file, "rb");
/* Is this a Blorb file containing Zcode? */
Scope-eye.net Git Repository / liskon_frotz.git / commitdiff