Metrocenter '84 - Inform 6 optimized for 8-bit targets

I reinstalled. Deleted all previous files in /usr/share/…

Compiling a game with the i6 wrapper uses I6 6.34.

All working as expected.

v/r
fos1

1 Like

Glad it is working now! My guess was that you might have had an old binary in path. The install routine of the MAKE file installs the Inform compiler to /usr/bin/inform6

The script should overwrite existing files but this hasn’t been tested on every machine and every scenario. You can always run the MAKE file with MAKE UNINSTALL to clean previously installed files before you update to a new version. Enjoy :slight_smile:

1 Like

It may have initially been the different installed versions. It is all sorted out now.

Thank you,
v/r
Jeff

1 Like

I wonder how you get it working:

~/if/eng/i6/inf634-2020/inftst -V
Inform 6.34 for Linux (21st May 2020)
~/if/eng/i6/inf634-2020/inftst -v3 botherin.inf botherin634.z3
Inform 6.34 for Linux (21st May 2020)
"/usr/share/inform6/library/linklpa.h", line 100: Error:  All 30 properties already declared (compile as Advanced game to get an extra 62)
> Property
"/usr/share/inform6/library/linklpa.h", line 101: Error:  All 30 properties already declared (compile as Advanced game to get an extra 62)
> Property
"/usr/share/inform6/library/linklpa.h", line 102: Error:  All 30 properties already declared (compile as Advanced game to get an extra 62)
> Property
"/usr/share/inform6/library/linklpa.h", line 103: Error:  All 30 properties already declared (compile as Advanced game to get an extra 62)
> Property

ecc. ecc.

of course, the library is the current one from Dave Griffith:

ls -l ~/if/2sort/inform6lib-master.zip 
-rw-r--r-- 1 pigi pigi 138291 mag 28 14:38 /home/pigi/if/2sort/inform6lib-master.zip

what I have overlooked ?

Best regards from Italy,
dott. Piergiorgio.

The Inform 6 library requires v4 or later. This has been true since Inform 6 was released, as far as I know.

If you want v3, you have to compile with the Inform 5 library, or one of the reduced-footprint libraries like PunyInform or Metro84.

2 Likes

What @zarf says :slight_smile:

Metro '84 is currently production ready.

PunyInfom is currently in Beta but @fredrik and the rest of the team is working hard to have it ready soon.

Hope this helps!

2 Likes

my, seems that I failed to disambiguate… :slight_smile:

1 Like

I’m sure I could go through the standard library and remove/fix the things that stop V3 from being a usable target.

[edit]

I’m also accepting merge requests to re-enable V3 in the Standard Library.

3 Likes

Metrocenter '84 version 1.2 is out now! This release adds (optional) number parsing routines to the library. To enable the feature set Constant ENABLE_NUMBERPARSING at the cost of 738 bytes. Please note that number tokes defined in your Grammar are only processed as number tokens when number parsing is enabled, which you probably guessed already.

2 Likes

Hoping not to restart the legendary flames of 1980s, but why the wrapper created an atari 8 bit disk image and not also, for example and without partisanship, commodore 8 bit, apple ][, trs80 disk images ?

Edit, oh, and please keep in mind that Linux is CaSE-seNSiTivE… already placed the relevant symlink, a SOP for me, np here :wink:

The goal of the wrapper tool is not targeting the whole range of 8-bit computers back from the day. I think it should be up to the author to decide which classic system and which interpreter they use for their game. For CPC for example, you could load up Infocom’s own interpreter, which was used for the UK releases of HHTTG and Planetfall, you could also use ZXZVM, a free interpreter for CPC and Spectrum +3 by John Elliott. It’s pretty easy to just create a Bash script, run the wrapper and then trigger the tools necessary to create a disk image of your game. Ozmoo for example does a pretty amazing job if you’re planning to target the Commodore 64. The whole process can be fully automated.

That leads us to the question why the wrapper does output an Atari 8-bit disk image. Because the Atari 8-bit computer is not the fastest of the old machines. If your code is performing well there, it will be performing well on other machines such as the Commodore 64 or the CPC.

1 Like

This is exceedingly cool. What are the tradeoffs of MC84 when it comes to library functionality?

Not many actually. Parts of the library are modular, so you explicitly need to enable clothing to use wearables or enable number parsing for the parser to recognize numerals.

A few things of course were cut: multiple object handling (take all, take three coins, etc), plurals, darkness, reduced look modes, reduced inventory list management, clock support, oops/undo processing, compound commands (open chest and take all from it), some lesser used verbs (but not many), he/she/it processing and a huge reduction of library responses (mostly by combining similar ones). Timers are limited to 4 and text input to 64 characters.

What remains though does retain a very Inform like look and feel. Here are some more details about what the library does and what it doesn’t.

3 Likes

sorry for the brief OT, but AFAICT the atari 8 bit was indeed one of the slowest 8 bit, but in BASIC; in assembler (and the 8 bit 'terps are written in assembler) was one of the fastest, a 1.77 Mhz 6502 (back then, my 8 bit machine was a C=64, clocked at .985 Mhz)

Best regards from Italy,
dott. Piergiorgio

ps. the clock are the PAL ones; the NTSC ones are generally slight faster

It is not only about clock speed here, this is generally about the interpreters, disk access speed and cache sizes for a story file.

Anyway, Atari 8-bit is given from the wrapper utility, which is sufficient enough to test the code on 8-bit, the rest is up to you. Ozmoo is a good starting point :slight_smile:

1 Like

nah, for me is sufficient building the .z3 story file; Anyway, was trivial removing the .ATR building from the shell script, so there’s no actual issues, only curiosity on your choice.

1 Like

Yes, and that’s the reason it is a Bash file, authors can suit it their needs. Glad it works for you!

Metrocenter '84 version 1.3 is out now. It introduces memory-efficient flags and a few more or less minor parser improvements. Get it from here https://github.com/ByteProject/Metrocenter84

1 Like

all works fine (compiles some of the eldest WIP here, a pair of I5.x from mid-to-late-90s…) but there’s a potential major issue for players:

q don’t ask for confirmation, and a quick look at a keyboard show the seriousness of the issue, considered that metrocenter don’t implement command sequencing , the most frequent usage of said sequencing being traversing locations (e.n.w.w.w. is a case-in-point example…)

for me is even convenient, for quick checks of typo or minor/trivial bug correction, but for a player, involuntary quitting the game for an easy typo, is a strong-languange issue…

Best regards from Italy,
dott. Piergiorgio.

4 Likes

Yes, chained commands are not supported. This has been inherited from mInform, where these features were taken out first. I’ll be backporting some of the greater features I’m missing, so this is not the end of the road. I see Metro’84 as an optimized version of the Inform 6 lib, suitable to target constrained systems. So with that in mind, some features that ease the life of authors (and help make the code more compatible for porting IF works) will be back in eventually.