PunyInform v3.6 released

You can manually alter the input buffer and the parse buffer, yes. What you can’t do, and which many Inform 6 translations rely on, is change/add/remove words in the input buffer and expect the library to lookup the words which are there after the modification and write the address of each of the words that are in the game’s dictionary. @tokenise is used automatically by the Inform 6 library to do this, after BeforeParsing() has been called, but it can’t be done in v3.

I can indeed alternate the buffer and rebuild the parse, I tried. For the address of the word in the dictionary I can look up the address myself; I had already done a routine like that. The problem is that it may take a lot of processor cycles…
Okay, thank you. I’ll leave it at that for now.

I think I can offer a first French translation fairly quickly using what I did for the translation of the standard 6.12 library.
A translation only makes sense if it respects the main purpose of PunyInform: “allow for games which are fast and have a samll memory footprint.”
Wait and see.

3 Likes

I guess for version 3, there is no possibility to translate the word ‘Score’ and ‘Moves’ in the status bar. As well as messages sent by the interpreter (version 3 or higher); unless you hack the interpreter.

That is of course so. The game can’t control the text strings built into the interpreter.

Ozmoo can interpret z5 files on C64, but on other old computers are there interpreters that can handle versions higher than z3?

In the PrintOrRun() function, in which case the first test (p_obj.#p_prop > WORDSIZE) is checked?

[ PrintOrRun p_obj p_prop p_no_string_newline _val;
	_val = p_obj.p_prop;
	if (p_obj.#p_prop > WORDSIZE || _val ofclass Routine) return RunRoutines(p_obj, p_prop);
	if(_val ofclass String) {
		print (string) p_obj.p_prop;
		if(p_no_string_newline == 0) @new_line;
	}
];

I directly call RunRoutines() in my new _PrintObjName(), so I dodge this first test which I can’t do because now the article property and either an array or a routine:

[ _PrintObjName p_obj p_form;
   if(p_obj hasnt proper && p_obj provides article) {
      if (p_obj.article ofclass Routine)
         RunRoutines(p_obj, article);
      else {
         if(p_form == FORM_CDEF)
            print (string) p_obj.&article-->0;
         else if(p_form == FORM_DEF)
            print (string) p_obj.&article-->1;
         else if(p_form == FORM_INDEF)
            print (string) p_obj.&article-->2;
     }
   }
	PrintShortName(p_obj);
];

Object confiture "confiture" room1
with
   name 'confiture',
   article "La " "la " "de la "
has;

I believe the only other 8-bit platform* to push past z3 was the Apple II line, which had z4, z5, and (unlike the C64) z6 releases. (And if I understand properly how Pitch Dark works, yes it has at least one third-party interpreter with support for z3-z6.)

The major 16/32-bit platforms of the mid/late 80s (DOS/Amiga/68k Macintosh) all had support for z3-z6. (Those are also pretty old computers at this point!) (I originally included the Atari ST because its fans insist it was a major platform. Obviously it was not, it didn’t get the z6 games. Sry MIDI guyz.)

*- technically the Commodore 128 also has its own z4 and z5 interpreter that runs in native C128 mode for games like Trinity, AMFV, and Beyond Zork because this question is apparently really difficult to answer concisely

I wasn’t aware that any of the V6 games were released for the ST line.

Gah! Fixed!

The Amstrad CPC now has a port of ZXZVM, which handles v5 and v8; ZXZVM was for the Spectrum +3 and Amstrad PCW originally.

Ozmoo has been ported to the BBC Micro and Acorn Electron, with (I think? I need to check again…) z5 support.

(All of this is third-party of course.)

1 Like

I had forgotten those, yet I had an Atari 520 ST… I was thinking of the 8-bit platform.
So the translation is interesting, especially for 16/32-bit platforms where the playability must be quite good.
The difficulty is that the font glyphs are not necessarily present.
And there are two things to consider about accents, the display of the text on the screen and the input. The problems can be quite different.

I wish the article had gone into more detail, but this diagram appeared in the Winter/Spring 1998 edition of The Status Line, in an article titled “What about Atari 8-bits and the Commodore 64”:

The entire issue can be found at http://infodoc.plover.net/nzt/NZT7.1.pdf and probably several other places as well.

2 Likes

This happens if there is an array of routine addresses, which is what you get for additive properties which belong to a class, like the before property here:

Class UntakableObject
  with before [; Take: "A strange force stops you!"; ];

UntakableObject GlassJar "glass jar"
  with
    name 'glass' 'jar', 
    before [; Open: if(has_gone_to_gym==false) "You're just not strong enough!"; ],
1 Like

I think we have drifted slightly off-topic for a PunyInform release thread…

Perhaps spawn new questions in new threads from here on? Even PunyInform-specific questions may deserve their own threads, just like all Inform 7 discussions haven’t been gathered into a single thread.

3 Likes

Infocom’s C128 releases need to be considered here, AMFV and Trinity for example. They were z4.

Sorry for being off-topic @fredrik!

1 Like

I was compiling Calypso with PunyInform 1.7, and I noticed that the resultant Z5 file was bigger than the other Calypso Z5 file I had which had been built with PunyInform 1.3 – 51KB versus 49KB, which is okay but slightly worrying if you’re thinking about packaging the game for use on 8-bit machines, where RAM and disk-space are at a premium.

Any idea why the Z5 filesize would have grown since 1.3? Are there parts of the Puny library I can “switch off” if I know a particular game won’t need them? Would that reduce the Z5 filesize?

EDIT: I see that calypso.inf already includes these two compiler directives on its first two lines:

!% -~S
!% $OMIT_UNUSED_ROUTINES=1

Glad to see you’re interested in the library!

The reason is simple: PunyInform wasn’t very mature when we released it four months ago. As people started to use it, they quickly discovered things that weren’t fully working. No new features have been added that would make sense to allow the programmer to turn off. Things like ship directions add some bytes of course, but are disabled by default and so don’t add to the size of Calypso.

These are the changes made between v1.3 and v1.7 which I believe have increased the size of the library:

  • Improved parsing of delimiters between direction commands.
  • Changed grammar of ‘get’ to match I6 lib. “get on object” and “get out of object” now work.
  • Added global receive_action to let receiving object know which action is happening.
  • Changed so the invent property is consulted whenever a list of objects is presented by PrintContents, most notably also affecting object listings in room descriptions.
  • Added calls to object parent’s before and after rules (if container or supporter) with LetGo action when taking object.
  • Fixed that PutOnSub didn’t call before- or after-rules for Receiver, and that InsertSub didn’t call before-rule for receiver.
  • Added checks to see if objects can be touched to many action routines.
  • Added call to AfterRoutines in WearSub.
  • Fixed TryToTakeNoun() so it clears concealed attribute when an object is picked up.
  • Printing the game banner has been moved to a routine named Banner(), just like in I6 lib.
  • A game can now make the library skip the game banner when the game starts, by returning 2 from Initialise(), just like in I6 lib.
  • with_key can now be a routine. The object which is currently being tested as key is held in second. with_key returns an object id, or false if nothing fits.
  • Run AfterRoutines() after taking inventory and it’s not empty, just like I6 lib.
  • Fake action ##Going is now sent to destination room’s before routine just before the player enters.
  • Improved disambiguation for plurals to make “get all red” work
  • Now allowing more than one word inputs in disambiguation
  • If bag is in box which is on table, and player is on table and types ENTER BAG, (s)he now gets “You have to enter the box first.” instead of “You have to leave the table first.”
  • GET ALL FROM [supporter] could make parser complain that the supporter isn’t open.
  • GET ALL FROM [object] would not take anything unless the object was a static or scenery object.
  • creature_object wasn’t properly handled by the parser.
  • Now inp1/inp2 are updated in PerformAction
  • Fixed ‘drop X’ parsing bug when X present but not held.
  • Look now sets the action to ##Look when calling AfterRoutines, even if Look was called by the Go action or some other action.
  • Made plurals trigger that object names are printed, so “TAKE BALLS” may print “red ball: Taken.”
  • GET ALL FROM BOX issued a ##Remove action for the first item and then a ##Take action for each of the remaining objects.
  • Held (GrabIfNotHeld) didn’t check implicit take status properly.
  • Fixed an error where “drop books” when not holding any books still referred to the first book in scope
  • Wrong word order in disambiguation caused parse_name to fail
  • Fixed error where multiinside silently ignored some inputs
  • Fixed: bad combinations of adjectives and nouns messed up disambiguation code
  • Made ‘unknown word’ messages customizable
  • Objects which have scenery or concealed no longer get the chance to be printed by Look, even if they have initial, when_open, describe etc.
  • Improved incomplete switch command replies
  • PunyInform now informs when the score goes down, as well as up.
  • Fixed ‘get all but X’ didn’t work like ‘get all Xs but Y’
  • Fixed bug in MoveFloatingObjects which caused objects to disappear if one floating object had absent attribute.
  • Fixed dropping objects when on a supporter bug
  • The parser can now correctly handle input like 'get all but ’ . Regression test added to getallfrom.inf to check this and similar patterns.

In summary, the parser is better, more things are customisable, the game author has more control over the actions, games are less buggy and the presentation to the player is better.

I tried compiling the latest version of Calypso as z5 using PunyInform v1.3 and v1.7. These are the file sizes, without padding:

With abbreviations: v1.3: 47884 bytes, v1.7: 48684 bytes
Without abbreviations: v1.3: 51620 bytes, v1.7: 52416 bytes

The size difference is 800 bytes with abbreviations and 796 bytes without. I don’t think that’s half-bad, considering how much better and complete the library has become.

6 Likes

That there’s room for improvement is out of question, as I have suggested above, suggesting aiming for .z3 late Infocom parser, but my suggestion is, if you add a TODO file when releasing punyInform 1.8 the feedback will improve, allowing a better prioritising of the remaining work to be done.

A suggestion, AFAIK no one has psychanalysed Lord Nelson ;), so I guess that is feasible reclaiming a precious attribute via:

Attribute absent alias female;

Best regards from Italy,
dott. Piergiorgio.

We have chosen not to have a todo file for PunyInform. Instead we have a (public) Trello board where everything that would be in a todo file can be found: Trello

There will always be room for improvement. And there will always be some who think the library should be more advanced, and some who think it should be more minimalistic. These people aren’t right. Neither are they wrong. It’s their personal, perfectly valid opinions.

We’re pretty happy with the library as it is now. We accept bug reports and suggestions via the Github issue tracker at Issues · johanberntsson/PunyInform · GitHub . If it’s a bug we usually just fix it. If it’s a suggestion we discuss it, decide what we want to do and reply and possibly make changes to the library. In any case, we really appreciate feedback, be it bug reports, suggestions for changes or just hearing from people who use the library.

There are cases where you want a ship computer to be present in a lot of rooms, or you could have an NPC following you around using the floating object mechanics, so I don’t think this is a good case for aliasing.

3 Likes