programming/hugo/release.txt

A BRIEF HISTORY OF HUGO - RELEASE NOTES
---------------------------------------
by Kent Tessman <kent@generalcoffee.com>

(See the file changelog.txt for specific changes post-v2.5.01.)


-----------------------------------------------------------------------------
v3.1 - 7-Aug-04

Version released in preparation for commercial release of Future Boy!,
which included v3.1.01 on the CD-ROM.


-----------------------------------------------------------------------------
v3.0.04 - March 2002

The next major step in the move away from v2.5.  Most ports (including
compiler and engine) are now v3.0, even if they don't provide the full set
of v3.0 capabilities (including menus, video, etc.).

Some ports are still compiled for v2.5, but are still able to run v3.0
games if compiled with the latest sources.  (And, of course, v3.0 engines
can run games compiled with a v2.5 compiler.)


-----------------------------------------------------------------------------
v3.0 - July 2000

The final integration of the v3.0 and v2.5.x codebases is complete,
and v3.0 finally gets released after its (lengthy) beta period.

Version 3.0 packages are available for Win32 and BeOS x86/PowerPC.  I will
continue to release v2.5 packages for Win32 for the immediate future, even
though they're essentially redundant (as v3.0 and v2.5 are intercompatible).


-----------------------------------------------------------------------------
v3.0 beta - April 2000

Further developments to the v3.0 architecture, including:

Video playback now takes optional volume and background arguments.  Volume
behaves the same as for 'sound' and 'music' statements.  The background
argument, if non-false, plays back independently of the normal engine loop
so that game play, player input, etc. continue.

	video [repeat], "resourcefile", "resource"[, <vol>, <background>]
	
New mouse functionality has been added (to v2.5, as well), so that a mouse-
click now passes keycode=1 to hugo_keywaiting(); also sets
display.cursor_column and display.cursor_row to the origin of the mouse-
click (in screen coordinates, measured in the fixed-width font).

(Various improvements have been made to the shared v2.5.02/v3.0 code as
well, for the compiler, engine, and debugger.  These are listed in detail
in changelog.txt.)


-----------------------------------------------------------------------------
v3.0 beta - April 1999

Lights, camera, v3.0 beta--now with support for new media types:  MIDI,
MP3, MPEG, and AVI.

The new command for playing back a video resource is:

	video [repeat] "<resourcefile>", "<videoname>"
	
The video image is displayed in the current window (as a still image is);
regular Hugo Engine execution is suspended until video playback either
finished or is interrupted.

Also, support for contextual command menus via the 'addcontext' command,
allowing, for example (under Win32), mouse-driven menus of relevant commands
to be dynamically generated by the game at runtime.

More details, including improved Latin-1 character set handling (actually
for v2.5.01) and full v2.5.x-v3.0 intercompatibility.  See the v3.0 addendum
to the Hugo Manual for the full story.


-----------------------------------------------------------------------------
v2.5 - August 1998

Sound, finally, in the forms of mod music (MOD, S3M, and XM formats) and 
WAV samples.  To play a song or a sample:

	music [repeat] "<resourcefile>", "<songname>"[, <volume>]
	sample [repeat] "<resourcefile>", "<samplename>"[, <volume>]

And to stop them:

	music 0
	sample 0

The 'repeat' token indicates that a module/sample should be played repeatedly
until it is either stopped or replaced by playing another.  If <volume> is
given, it must range from 0 to 100, and will remain in effect until a new
volume is given.

New compiler switches and defaults, as well.  The '-t' switch will list all
printed game text to the screen or .LST file (if '-l' was also specified).
Expanded-format error/warning messages and verbose compilation (updating
the number of files/lines compiled) must now be explicitly with the '-e' and
'-v' switches, respectively.  Plus there are handy new warnings, such as one
that warns you if a noun or adjective contains an uppercase character.

Internal enhancements include a major optimization of the engine's call/
conditional stack management, resulting in substantial speed and efficiency
gains.  I've also revisited the printing mechanism in order to make
the coordination of windowing, proportional printing, and font styles much
easier for porters.

A new display object property, title_caption, allows a program to
optionally set the title of the screen/window (if the system allows it) 
via:

	display.title_caption = "Colossal Cave"

The new library constants DEF_SL_FOREGROUND and DEF_SL_BACKGROUND (integer
values 18 and 19) can be used in a 'color' statement to refer to the default
statusline colors for the current port.

I've also split hugolib.h, the Hugo Library, into hugolib.h and verblib.h,
where the former contains the core game-world management and the latter 
is made up solely of verb routines.  For consistency, grammar.g has been
renamed verblib.g.  (In conjunction with the library split, a VMessage
routine is now called by verbs; Message is still the name of the message
routine called by the core library.)

The 'system' token has been revived, and can be used as a built-in function
as:

	system(11)	READ_KEY
			- return a key value if a keypress is waiting, or
			  else 0
			  
	system(21)	NORMALIZE_RANDOM
			- once called, random numbers will follow a
			  reproducible pattern
			  
	system(22)	INIT_RANDOM
			- restores "random" random numbers
			
	system(31)	PAUSE_SECOND
			- pauses the engine for 1 second
			
	system(32)	PAUSE_100TH_SECOND
			- pauses the engine for 1/100th of a second
			
Constant definitions (i.e., READ_KEY for 11) are contained in "system.h".

A new engine global called 'system_status' may be checked after a resource
operation or 'system' call.  If zero, status is normal.  If non-zero, it
will contain one of the following values:

	 -1	STAT_UNAVAILABLE
	101	STAT_NOFILE
	102	STAT_NORESOURCE
	103	STAT_LOADERROR
	
(STAT_UNAVAILABLE is the only potential response for a system() call.)

Constant definitions are again in "system.h".

A new parsing feature is an extension to ParseError where if a user
ParseError routine returns 2 (instead of simply true or false), the
entire grammar-matching mechanism is re-triggered.  This is useful for
cases where a peculiar syntax is trapped as an error, reconfigured by
ParseError, and should then be re-parsed.

Also a 'punctuation' extension has been added that works similarly to
a removal, but instead of a whole word only removes a particular character
from the input string so that a user can custom-define punctuation, as in:

	punctuation "%$"
	
which will remove any '%' or '$' character from typed input.


-----------------------------------------------------------------------------
v2.4 - August 1997

Version 2.3f became v2.4 when I realized that, gradually, v2.3 had advanced
an appreciable bit with v2.3a-v2.3e--enough, at least, to warrant a new
revision number.  (Another reason is that adding the new graphics and
windowing capability and object-orienting the display required a version 
change in order to ensure backward compatibility.)  At the same time, a 
version jump enabled me to incorporate some other advances and features that 
had been put off for v2.3x releases because of the compatibility issue.

The most noteworthy feature is that graphics-capable ports may now load
pictures (in JPEG format) into the currently defined window using:

	picture "<resourcefile>", "<picturename>"

Resourcefiles are created by the compiler via:

	resource "<resourcefile>"
	{
		"<picture_filename1>"
		"<picture_filename2>"
		...
	}

A new 'display' object is created automatically by the compiler (if not
otherwise provided).  The display object has the following default read-only
properties:

	display.screenwidth
	display.screenheight
	display.linelength      replaces v2.3 linelength global
	display.windowlines     replaces v2.3 pagelength global
	display.cursor_column
	display.cursor_row
	display.hasgraphics

The 'window' statement has been enhanced as follows:

	window 0                restores full-screen output; there is no
				following {...} code block

	window n                creates a window of n lines beginning
	{...}                   at the top of the screen

	window x1, y1, x2, y2   creates a window with the top-left corner
	{...}                   (x1, y1) and bottom-right (x2, y2)


	window                  with no parameters, redraws the last-
	{...}                   draw window

Upon termination of the {...} code block, the main text window is re-
defined as ending immediately below the last-drawn window.

Enhanced conditional-compilation constructs '#if', '#elseif' and '#else'
in addition to '#ifset' and '#ifclear' make complex source code easier to 
read.  New compiler conditionals '#if defined' and '#if undefined' allow
checking if objects, properties, etc. exist.  Internally, the linker has
been restructured for speed, accuracy, and clarity.

A benefit to users on memory-rich machines is the ability of the engine
to load the entire game file into memory at invocation.  If not enough
memory is available, it will continue to read text-bank strings from disk.
Static print strings (i.e., using "print ...") are no longer limited to a
single byte (255 characters) in length.  Conveniently, the 'parse$' and
'serial$' read-only engine variables now represent constants that can be
read in a wider range of contexts, and may be assigned to other variables 
or data structures, etc.

The debugger now recognizes local variables by name, instead of "local:n".

And finally, a player_character class has been added to OBJLIB.H with some
additional flexibility in terms of built-in before routines, etc.


-----------------------------------------------------------------------------
v2.3c/d/e/f - April-May 1997

I haven't been in the habit of updating these release notes for interim
releases (i.e., same-version updates), but a couple of recent revisions are
worth mentioning in addition to the usual polishing and tweaking--some of
which, to the compiler's tokenizing methodology, have resulted in significant
performance improvements using a rather guerilla form of hash-search 
string-matching.

It is now possible to pre-declare locals as in:

	local i = 1, j, k

The statement "colour" may now be used interchangeably with the
original "color".

Parentheses can be used where they previously could not, for example, in
nested multiple-choice conditional sub-expressions such as

	if y = 4 and (x = 1, 2, 3)

where the "x" sub-expression is now always evaluated first.

The accompanying v2.3.2 library allows the player object to be referred to
by the library in first, second, or third person depending on the setting
of the player_person global.  The player object must help out a bit by giving
the correct set of pronouns.  For example, the normal second-person player
object "you" in SHELL.HUG now contains:

	pronouns "you", "you", "your", "yourself"

Additionally, it is now possible to refer to an object with up to 16 words in
the input line--i.e., up to 16 adjectives, or 15 adjectives and 1 noun.


-----------------------------------------------------------------------------
v2.3 - March 1997

The month of fairly rigorous testing and refinement between v2.3's beta
release and the official release resulted in at least a couple of highly
functional extensions to object building:

	replace <objectname> "name"
	{
		inherits <class1>, <class2>,...
		...
	}

The "replace" directive is useful for replacing previously defined objects
or classes without having to actually edit the file in which they first
appear.  A popular example is the room class from OBJLIB.H:  often,
programmers have wanted to give their basic room classes special properties.
This is now easy via:

	replace room "room_class"
	{
		(...new room definition...)
	}

The "inherits" instruction allows more than one class to be used to build
an object.  The precedence of inheritance is left to right, i.e., the
properties of <class1> take precedence over <class2>, etc.

(Both "replace" and "inherits" were based on suggestions by Jools Arnold.)

Mark Bijster offered the following:

	object is <attribute1>[, [not] <attribute2>,...]

which is now valid in a line of code, so that multiple attributes can be set
or cleared for the same object at one time.

A couple of changes to the debugger accompany v2.3.  An online help file is
now available (HDHELP.HLP), giving information on the debugger's various
functions and features.  In terms of deletions, the ability to launch the
compiler or an editor has been removed--mainly because in larger systems, it
is relatively easy to switch back and forth between multiple programs, and
on smaller systems (such as MS-DOS), memory constraints prevented launching a
new process anyway.  (In short, this sort of process spawning wasn't
particularly portable.)

A tidied up version of the libraries accompanies v2.3.


-----------------------------------------------------------------------------
v2.3 beta - February 1997

A small step forward in refining the Hugo language, but a major leap in
terms of expanding the functionality of the Hugo design environment.

Version 2.3 includes a full-featured source(ish) level debugger enabling
a Hugo programmer to utilize breakpoints, watch expressions, code tracing,
and most other modern IDE features to debug programs.  It is not
technically a source-level debugger in that it is tracing the compiled
object code, not the original source file(s), but the output is similar
enough to be useful in the same way.  Big thanks to my brother Dean Tessman
for his input on the user interface.

Enhancements to the language allow the use of efficient operators '++'
and '--' for pre/post-increment/decrement, as well as '+=', '-=', '*=',
'/=', '&=', and '|='.  Those unfamiliar with these somewhat cryptic yet 
exceptionally useful operators are referred to the Hugo Manual for
further explication.

Another new feature is the "enumerate" directive, as in:

	enumerate start=5, step *2
	{
		FIRST_CONSTANT, SECOND_CONSTANT, THIRD_CONSTANT
	}

which is equivalent to

	constant FIRST_CONSTANT   5
	constant SECOND_CONSTANT 10
	constant THIRD_CONSTANT  20

Globals may also be enumerated via "enumerate globals [start..., step...]".

(Both the efficient operators and constant/global enumeration have come
into being at the urging of Mr. Jools Arnold.)

As a final constant-initialization enhancements, constants no longer need to 
be declared with an explicit value.  If none is provided, the constant is 
assigned a value that is unique from any other constants declared without 
an explicit value, so that in

	constant THIS_CONSTANT
	constant THAT_CONSTANT

THIS_CONSTANT and THAT_CONSTANT can be referred to meaningfully as
different values, flags, etc.

Further compiler enhancements include stricter syntax checking to avert 
potential runtime errors, the ability to pre-initialize local
variables, as well as compile-time warnings of unused locals, and the
option (for legibility) of defining an event as "event in <object>"
instead of simply "event <object>".

Other quick additions and fixes:

	- "array[]" now returns the number of elements in the array

	- "&(obj.property1).property2" no longer incorrectly takes 
	  the address of <property1>

	- it is now possible to specify the input color via a third 
	  parameter in the color statement:
	  "color <foreground>[, <background>[, <input color>]]"

	- quirky attribute behavior has been isolated and reined in

A stylistic syntactical change involves constructions such as

	object.property1.property2

which used to be read as

	object.(property1.property2)

These are now interpreted left-to-right, so that the order of processing is

	(object.property1).property2

This is a.) more consistent with other common object-oriented languages, and 
b.) plain old more intuitive.

The behavior of FindObject and the engine's expectations for it have been
refined so that, for example, object disambiguation is more accurate, and
parse_rank now works properly in a wider variety of circumstances.

As far as deletions to the language go, "~" and "^"--which existed briefly
as equivalents to "\"' and '\n' in print statements for Inform users
familiar with the former symbols--are no longer significant in printed text.

Thanks to Dean Tessman, Julian Arnold, Jim Newland, Cam Bowes, John Menichelli, 
Jerome Nichols, and everyone else who has made contributions large and small.


-----------------------------------------------------------------------------
v2.2 - July 1996

While on the surface not much different from v2.1, v2.2 contains a range
of revisions, enhancements, and extensions.  Here's a quick rundown:

Text output has been greatly expanded in terms of flexibility and capability,
allowing (if the system in question supports it) boldface, italics,
underlining, and proportional type.  Special characters such as accents
are now easily printable.  In conjunction with these changes, the library
printing and listing routines have been revised, and (most of) the printed
text has been localized at the ends of HUGOLIB.H and OBJLIB.H.  Additionally,
text may now be routed to a memory (array table) address instead of the
screen.

Changes in how expressions may be structured now allow

	if x = 1, 2, 3

to be used instead of:  if x = 1 or x = 2 or x = 3, and

	if a = "apple" and b = "orange" and
		c = "banana"

to be split across multiple lines, providing it ends in "or", "and", or ",".

The Init routine is no longer called with the arguments (MAX_OBJECTS,
MAX_LINE); these are now referenced by the new globals objects and
linelength (and there is a new global pagelength).

The random(n) engine function now returns a random value from 1 to n, a
change that Jim Newland suggested was more intuitive and consistent
(although the current manual incorrectly and unfortunately gives the
range as 0 to n).  Array references are now all word-based, instead of
previously where references involving calculations such as a[b+3] were
byte-based.  Property routines may now be indirectly run with
object..property.  And grammar lines may now use the "word" token to
specify any single dictionary entry.

Extensions such as file i/o and command recording/playback have been
added, as well as a machine-independent compressed saved-game format--and
the engine now requires a confirmation if a save request will overwrite
an existing file.

Enhancements to the command line allow directories to be specified for
different types of files.

Finally, there has been the usual fine-tuning to the compiler (particularly
with regard to source-file processing and temp file usage) and the engine
(mainly the expression evaluator) to increase speed and performance.


-----------------------------------------------------------------------------
v2.1 - March 1996

Version 2.1 includes a number of substantial (although not earth-
shattering) improvements to both the compiler and the interpreter.
Foremost among these are the increase in the number of available attributes
from 32 to 128, more elegant compiling and linking (and error messaging),
more explicit run-time tracing of loop constructs, and a much, much faster
expression evaluator.

As well, the (also faster) text-printing routine in the engine has been
enhanced to allow the use of ~ and ^ in printed text to mimic \" and \n
(the quotation mark and newline characters); this feature was added at
the request of a number of Inform users who find them familiar and easier
to work with.  And string constants can now be extended over more than one
line without using the backslash ("\") at the end of the unfinished line.
(The backslash is still necessary for non-string-constant expressions, etc.
that stretch over more than one line.)

The author also managed to track down one particularly troublesome bug that
prevented the coding of a complex assignment such as:

	<object>.<property> [#n] is <attribute>

(Also note:  #n is no longer passed as the first argument to a property
routine.)

The library files include some major developments.  Primarily, the object
library (OBJLIB.H) now includes advanced classes such as plural and
identical objects, attachables, and components.

HUGOLIB.H has also been fine-tuned.  The routines DefArt, CDefArt,
IndefArt, and CIndefArt (hold-overs from the author's introduction to
interactive-fiction programming via the early Inform library) have been
replaced with The, CThe, Art, and CArt, respectively--a somewhat subjective
choice, perhaps, but one that lends it self to clarity of reading, and
which is both easily corrected in existing files using search-and-replace
as well as being nicely less cryptic.

Object listing has been enhanced--particulary the routines DescribePlace,
ShortDescribe, WhatsIn, SpecialDesc, and ListObjects.  The LISTTYPE global
no longer exists; it has been replaced by FORMAT.  As well, those users
who have begun projects using the v2.0 starting-block program SHELL.HUG
will want to remove the list_contents property from the player object.

And of course, the obligatory enhancements of the Vault of Hugo sample game,
Colossal Hugo, and Spur have been released to accompany version 2.1.


-----------------------------------------------------------------------------
v2.0 - November 1995

(Those keeping score may have noticed that v1.3 was never officially
released.  And admittedly v2.0 is not the full-featured, bells-and-whistles,
CD-ROM-driven animation and sound version.  But the changes to the actual
framework and functionality of the compiler have been so substantial since
v1.2 that it started to seem less sensible to keep Hugo at a version 1
level.)

The biggest new feature in version 2.0 is the ability to precompile header
files like HUGOLIB.H into .HLB files that may be included using the #link
directive instead of #include.  A new compiler switch -h is provided to
specify creation of an .HLB precompiled header instead of a normal .HEX
Hugo object file.

Thanks to the Hugo users who saw the value of allowing some form of linking,
and thanks also to the author's lack of sensibility in vastly underestimating
the work involved in reverse-engineering a non-linking compiler to accomplish
the task.  I'm going to get some sleep now.

Other streamlining changes have included the removal of the -t, -m, -n, and
-f switches (for compilation tracing, monitoring, numerical code generation,
and full-object summaries) since 1.) the amount of output produced using any
one of these become almost overwhelming when compiling a program of any
significant length, and 2.) few programmers, if any, made use of them
anyway.

The performance speed of the Hugo Engine has been increased by redesigning
the way it processes conditional statements.  The engine is now able to
work much more quickly through a complex series of 'if's, 'select's, 
'do-while's, etc.

Accompanying version 2.0 is also Spur, a western adventure written by the
author, as well as an extensive demonstration of what Hugo can do.  (In
fact, the greatest use of version 1.3 was as an interim development tool
for Spur.)

(NOTE:  A pre-Christmas touch-up release of v2.0 included some minor
fixes to the compiler, engine, and library.  Special thanks to David Kinder,
whose feedback helped increase the portability of the Hugo source code.)


-----------------------------------------------------------------------------
v1.3 - August 1995

Some significant enhancements to the compiler and interpreter, as well
as the library--enough so, in fact, that the author considered making
this v2.0, but held off as it has been suggested in the past that v2.0
will be the full bells-and-whistles, CD-ROM graphics and sound version.

The most significant changes were to accommodate large programs, which
would run into problems if the size of the total data space exceeded 64K.
The fix required involved altering the internal format for storing
reference addresses.  And some further refinement of the file format
has--thankfully--eliminated the need for a separate .H$$ text bank file;
everything is now self-contained in .HEX.  (These were the almost-v2.0
changes.)

Also, property routines now always pass the number of the property
element referenced as the first-defined local in the routine (if any is
defined), so that if 'object.property #x' is called, and <property> is
a routine, <x> is passed as the first local.  The only effects on
programmers are that 1.)  It is now possible to return more than one value
from a property routine, depending on how it was called, and 2.)  The
first-defined local can no longer be expected to equal 0, as is usually
the case in a normal routine.

It was decided that all compiler directives must now be prefixed with a
C-ish "#"--i.e. '#include', '#ifset', etc.  This not only makes the source
code easier to read, but increases compiler speed.  Other fine-tuning and
optimizations increased compilation speed by as much as 25 percent.  (And
another directive, '#version', is provided--and used in the library files--
to ensure that #included files are compatible with the latest Hugo features.)

Changes in format to engine commands and functions include:

	string(<array>, <dictentry or parse$>, <maxlen>)

(making the StringCapture library function obsolete), and

	save, restore, restart, scripton, and scriptoff

all of which must now be read as values instead of simply issuing a
simple command.  Return values (1 if successful, 0 if not) should now
be checked where appropriate, i.e.:

	if not save:  "Failed."

An 'undo' function (checked in the same manner as save, restore, etc.) is
now provided to undo the last player command.  (Multiple-turn undoing
is allowed as long as undo information exists in the undo buffer.)

It is also possible to use the token 'string' in a grammar syntax line
to allow the player input to contain a quoted string.  The string is
passed to the verbroutine in parse$, and may then be written to a string
array via "string(<array>, parse$, <maxlen>)".

The new command 'dict', as in

	x = dict(<array or parse$>, <maxlen>)

allows a new dictionary entry to be dynamically created at runtime
(although space for the total number of entries that may ultimately be
created must be reserved during compilation--in bytes--by setting the
MAXDICTEXTEND limit).

Additions to the library included the NumberWord routine as well as a
(small to begin with) set of math routines.  Properties such as
inv_desc and list_contents now make it even easier to customize the
listing of objects.  As well, some work was done with how the library
treats scenery objects--their contents (if any) are now listed by default,
even if the object itself isn't.

New string array routines include StringCompare, StringDictCompare, and
StringEqual.  New character script routines include CancelScript,
PauseScript, ResumeScript, and LoopScript--not to mention the fact that
RunScripts now checks before/after routines for the actor.

A major improvement to before/after routines is in the usage specification,
so that

	parent(object) DoGet

replaces

	parent DoGet

and the library now does checking for the special before property in the
DoGet routine.  What this means is that programmers may now check
any before or after routine/object combination instead of the previously
pre-determined object, xobject, location, and parent.

Thanks again to Vikram Ravindran for excellent suggestions on where
Hugo's functionality could be extended (particularly on supporting
the implementation of 'dict' and 'undo', as well as library improvements big
and small), and to Jim Newland for his extensive investigation into--and
subsequent notes to the author on--how the character script routines might
be expanded to further increase their usefulness.

NOTE:  Due to enhancements to certain key aspects of the Hugo language, it
is recommended that programmers who may already be familiar with it take a
moment to browse through the v1.3 manual, revisiting in particular the
sections on before/after property routines, string arrays, and character
scripts.


---------------------------------------------------------------------------
v1.2 - July 1995

This time at the end of the month.

Hugo version 1.2 was moved ahead mainly in response to requests by
porters for more easily portable code.  As a result, the H*HEADER.H
files were changed somewhat, with the porting-required functions moved
into separate .C files to make the job of adapting Hugo to different
operating systems more manageable.  (Thanks especially to Jesse McGrew
for the suggestion.)

Changes to Hugo at the most basic levels were relatively minor, except
that compilation speed is about 20% faster (and engine execution is
faster as well) because of Jeff Jenness's suggestion to limit the
number of C strcmp() calls performed.  The greatest changes here were
in STRINGFN.C, and HCMISC.C in the SeparateWords() function.

A couple of new constructs have been added to the language, particularly

	for <variable> in <object>

loops, the ability to specify values as ASCII characters as in

	'A', 'z', '7'

and print them as characters using

	printchar <value>

As well, it is now possible to specify an array address using a variable
or other value, as in:

	x = testarray           ! i.e, the address of testarray[]
	print array x[5]        ! the same as:  print testarray[5]

And finally, there is now a STRING command

	string <array>, <word>, <maximum length>

which reads the dictionary word <word> into the array given by <array>,
to a maximum of <maximum length> characters.  A number of string-
manipulation routines were subsequently added to HUGOLIB.H:
StringCapture, StringCopy, StringLength, and StringPrint.

Error trapping is also considerably tighter, lessening the number of
almost-correct lines which might slip through the compiler only to
crash the engine at runtime.

Thanks also to Vikram Ravindran for spotting a couple of problems
in Colossal Hugo (mainly involving attributes that were not properly
assigned when needed in certain object definitions), as well as
identifying a problem in HUGOLIB.H's DoGo routine which moved the
player to a null room upon entering 'go vault' in the sample game.
Thanks to Markus Mattes for suggesting a better fix than the one the
author had in mind...


-----------------------------------------------------------------------------
v1.1 - July 1995

After a couple weeks of error-reporting and user-testing, I went about
trying to address the two major problems with v1.0:  i.e. memory shortages
and the lethargic compile speed.

Thanks especially in this case to Dr. Jeff Jenness, who pointed out to me
that life does exist beyond MS-DOS, and that it may highly susceptible
to stack abuse.  Jeff also suggested moving dictionary search/store
management into memory as opposed to doing it in a work file.  This change
alone practically doubled compile speed--on the trusty 8086, SAMPLE.HUG
compiled in just over 300 seconds--and the programming required to
implement the far-model arrays (MS-DOS programmers may flinch here in
painful recognition) enabled many of the storage arrays such as for
objects, properties, etc. to be changed from static arrays to dynamically
allocated memory blocks.  The benefit:  increased limits for whatever
storage types the user may desire, and no more memory problems when, for
example, setting DEBUG instead of DEBUG_SMALL in COLOSSAL.HUG.

Changes to HEHEADER.H:  Far-model memory allocation and pointer declaration
for objects, properties, dictionary, etc.  Making the applicable MAX<limit>
declarations dynamic integers instead of constant #defines.

HEMISC.C:  AddDictionary() now searches a memory-based array instead of a
temporary work file.  OpenFiles() takes care of allocating space for
objects, properties, dictionary, etc.  New functions ListLimits() and
SetLimit(), as well as provision for $<setting>=<new limit> specification
in the invocation line via an addition to ParseCommandLine() (once again
following in the footsteps of another of Graham Nelson's excellent ideas
from Inform).

Additionally, there were minor additions/changes to the other compiler
and engine source files, as well as to the Hugo library files.  (One change
to SAMPLE.HUG was important--particularly to the author's self-respect.
Seems that in revising the methods of player-character interaction, he
actually omitted the means of solving the sample game.)


-----------------------------------------------------------------------------
v1.0 - June 1995

Hugo v1.0 was essentially the first full-featured, portable version of
the compiler and engine written in C (and based on a MS-DOS-only
Microsoft QuickBASIC beta release).  It was intended from the beginning
to be a functional beta release--i.e. one which would serve to point
out shortcomings and needed improvements with Hugo's design, but with
which users would also be able to start developing programs that would
be fully compatible with later releases.

The most obvious shortcomings were in memory management and compilation
speed.  On the machine the author used for development--an 8086, the
machine of necessity, not of choice--the sample game SAMPLE.HUG took
more than 600 seconds to compile.  And larger programs ran into memory
limitations, in one instance prompting the creation of the scaled-down
DEBUG_SMALL HugoFix command set instead of the regular set included via
setting DEBUG in the source file.

Also at this time, the first version of COLOSSAL.HUG was released--a Hugo
port of Adventure based on Graham Nelson's Inform port of David Baggett's
TADS adaptation of Crowther and Woods's original classic game.  (Quite a
lineage.)